martes, 30 de abril de 2013

Salto de pantalla de bloqueo en Android a través de Viber

La aplicación de mensajería y VoIP Viber, añade un método (de los que han aparecido en los smartphones en los últimos meses) para eludir la pantalla de bloqueo, esta vez solo para sistemas Android. El fallo es provocado por un mal control del bloqueo de la pantalla. Viber Media ya ha publicado una nueva versión que lo soluciona.

Viber es una aplicación de mensajería y VoIP para smartphones que permite realizar llamadas utilizando la red WiFi o 3G. También permite compartir con otros usuarios imágenes, vídeo, audio e  información de posicionamiento. Existen versiones para iOS, Android, Windows Phone (incluida la versión 8) y Symbian, entre otros. La red de Viber alcanzó 175 millones de usuarios entre todos los sistemas el pasado febrero.

La firma de seguridad vietnamita Bkav ha descubierto un fallo en el manejo del bloqueo de pantalla realizado por Viber. Este fallo puede permitir a un atacante que tenga acceso físico al dispositivo eludir la pantalla de bloqueo y así tener acceso total al sistema.

Para ello, solo es necesario saber el contacto de la víctima y que esta tenga Viber instalado en su terminal. Así, se pueden enviar mensajes a través de la mensajería de la aplicación al dispositivo, hacer aparecer el teclado y, a través de distintos pasos dependientes del terminal, desbloquearlo sin necesidad de conocer la combinación de seguridad.

El fallo se debe a un mal uso de los permisos de la aplicación. Existe un permiso que permite a las aplicaciones desactivar el bloqueo (por ejemplo, para responder a una llamada entrante). Viber hace uso de este permiso, pero parece fallar en el control del bloqueo cuando se realizan estas acciones.

Bkav ha publicado una serie de vídeos donde demuestran la explotación del fallo. Por ejemplo, para Google Nexus 4 y HTC Sensation XE:

Viber Media ya ha puesto a disposición de los usuarios la versión 2.7, que soluciona este problema. Sin embargo, esta actualización no está disponible a través de Google Play, por lo que los usuarios del servicio deberán descargar el paquete de la aplicación directamente desde el enlace que se ha proporcionado a tal efecto.

Para mayor seguridad en el futuro, es posible desactivar el comportamiento predeterminado de ventana emergente para los mensajes a través de las opciones de la aplicación.

Más información:

Critical flaw in Viber allows full access to Android Smartphones,
bypassing lock screen




Francisco López

lunes, 29 de abril de 2013

Múltiples vulnerabilidades en el proyecto grid BOINC

El proyecto BOINC ha actualizado recientemente sus versiones cliente y servidor para corregir múltiples vulnerabilidades que podrían afectar a los usuarios de la red y sus proyectos.

BOINC (Berkeley Open Infrastructure for Network Computing) es una red global de computación voluntaria, creada por la universidad de Berkeley y utilizada ampliamente por millones de usuarios para disponer de redes de ordenadores dedicados al análisis de datos que requieran una gran potencia de cómputo, relacionados generalmente con proyectos transcendentales como médicos (análisis del genoma, DNA@Home), meteorológicos (Climateprediction.net) o incluso astronómicos como el conocido SETI.

La red distribuida (grid) necesita de un cliente para acceder y poder disponer de la potencia de cómputo del ordenador conectado en ese momento así como un servidor que gestione y distribuya las peticiones de cómputo en cada momento.

Las vulnerabilidades que se han solucionado son las siguientes:


  • Diversos desbordamientos de memoria intermedia basada en pila en el parser XML (CVE-2013-2298), tanto en la versión cliente como servidor v7.x, y en la gestión de elementos ‘file_signature’, afectando esta vez sólo a las v6.10.58 y v6.12.34.
       
  • Varias inyecciones SQL, en la parte servidor del planificador (boinc_db.cpp), y en el apartado web “team_search.php” vulnerable a través del parámetro ‘type’.

Las vulnerabilidades así como otras funcionalidades han sido corregidas en las nuevas versiones 7.0.64/7.0.65 disponibles al público desde:


Más información:

Multiple vulnerabilities in BOINC

Proyectos que usan BOINC:
  


José Mesa Orihuela

domingo, 28 de abril de 2013

Últimas versiones del virus de la policía y más ideas para protegerse

El virus de la policía continúa evolucionando, con altos niveles de infección y nuevas estrategias fundamentadas siempre en la misma premisa: el secuestro del ordenador con la excusa de que, ante la detección de actividad ilegal en el sistema, es necesario pagar una multa a la policía. Veremos qué ligeros cambios se han observado en las últimas versiones y una idea para protegernos.

Las últimas versiones aparecían en forma de DLL. Era necesario llamarlas conociendo el nombre de la función de entrada del binario para poder ejecutarlo. Esta estrategia podía estar orientada a intentar eludir los sistemas de ejecución automática y desatendida de los laboratorios, puesto que la DLL pasaría a veces inadvertida si no se llamaba a la función concreta. Estas muestras solían instalarse en la carpeta de inicio.

En los últimos tiempos se ha observado que el malware ha pasado a utilizar un archivo con extensión .DAT (y de nombre skype), que no es más que un ejecutable (cuyos dos primeros bytes son MZ). Esto no es un problema para que sea lanzado, pero sí podría confundir a usuarios y análisis. Además crea un skype.ini. También ha vuelto a los "orígenes", anclándose en una rama del registro donde se lanza el explorer.exe. Veamos cómo funciona.

El ejecutable, fundamentalmente, busca el %APPDATA% del usuario, puesto que en Windows 7, podrá escribir sin problemas en él. Ahí dejará el archivo skype.dat (ejecutable).


En el registro, acudirá a la rama de usuario (también porque puede escribir sin problemas en ella) donde se lanza explorer.exe (proceso encargado de dibujar el escritorio y delegar los tokens de seguridad). Ahí se añade como ejecutable que será lanzado al inicio. Es muy extraño que un usuario necesite modificar ese punto del registro, así que podría ser protegido por permisos. Esto ya lo hace la herramienta WinLockLess, negando por permisos de registro la escritura en los puntos habituales que utiliza el ramsonware.




Pero también es posible tocar los permisos NTFS de la máquina, para evitar que se escriba en un punto clave que están usando tanto los creadores del virus de la policía como el malware en general. %APPDATA% es una variable que apunta habitualmente a

C:\usuarios\nombreusuario\appdata\roaming

Ahí se almacena información de los programas del usuario y su configuración privada. En esta carpeta es muy extraño que se creen ficheros. No suele ser necesario. Normalmente son directorios que alojan archivos con datos. Todavía más extraño es que se necesite ejecutar código desde la raíz de %APPDATA%.

Por tanto, de nuevo, utilizar los permisos NTFS (siempre demasiado relajados por defecto) puede mitigar el problema. Podemos decirle a Windows que impida la ejecución de ficheros desde esta carpeta, pero que siga permitiendo crear carpetas e, incluso, archivos... pero que no los ejecute.

Gráficamente es muy simple. En las propiedades de la carpeta Roaming, Seguridad, Opciones Avanzadas, Cambiar Permisos, Agregar. Ahí añadimos que "Todos" no puedan explícitamente ejecutar archivos. Importante indicar que esto se aplica a "Solo archivos".



Con esto no se evita la infección, pero sí que en el siguiente reinicio se ejecute el fichero. Si se desea, también se puede evitar la escritura de ficheros en la raíz de Roaming.

Por línea de comando, se puede llamar a:

icacls %appdata% /deny *S-1-1-0:(OI)(IO)(X)

Donde "(OI)(IO)" indica el "Solo ficheros", el "X" la ejecución, y "S-1-1-0" es el SID del usuario "Todos" en los Windows.



Importante apreciar que en Windows XP, por implementar una versión ligeramente diferente de NTFS, es posible seguir estos pasos pero no tendrán exactamente el mismo comportamiento.

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

sábado, 27 de abril de 2013

Ejecución de código en productos F-Secure para servidores

F-Secure ha publicado un boletín de seguridad que corrige una vulnerabilidad de alto riesgo en varios de sus productos para servidores. El fallo podría permitir la ejecución de código SQL arbitrario en el sistema afectado.

La vulnerabilidad se debe a un error en un componente DLL relacionado con el control ActiveX, que podría permitir conexiones con el driver ODBC (Open DataBase Connectivity, un estándar de acceso a las bases de datos) cuando se utiliza el navegador web Internet Explorer.

Un atacante podría explotar esta vulnerabilidad y lograr ejecutar sentencias SQL arbitrarias persuadiendo a un usuario para que visite un sitio web especialmente diseñado si el servidor local utiliza laautenticación local.

La vulnerabilidad ha sido descubierta por Andrea Micalizzi, alias rgod, y no dispone de identificador CVE.

Los productos afectados son los siguientes:


  • * F-Secure Anti-Virus para Microsoft Exchange Server 9.x
  • * F-Secure Anti-Virus para Windows Servers 9.00
  • * F-Secure Anti-Virus para Citrix Servers 9.00
  • * F-Secure Email y Server Security 9.20
  • * F-Secure Server Security 9.20
  • * F-Secure Protection Service para Business (PSB) Email y Server
  • Security 9.20
  • * F-Secure Protection Service para Business (PSB) Server Security 9.20

F-Secure ha publicado parches que se encuentran disponibles en el FTP oficial (ftp://ftp.f-secure.com/support/hotfix/) para todos estos productos, salvo para PSB cuya actualización se realiza de forma automática.

Más información:

FSC-2013-1: Remote code execution vulnerability in DLL component

F-Secure FTP


Juan José Ruiz

viernes, 26 de abril de 2013

Las vulnerabilidades más usadas por los kits de explotación

Recientemente se ha publicado la última versión de una tabla colaborativa en la que se detallan qué "exploits packs" intentan explotar qué vulnerabilidades además de otros datos relevantes sobre los kits y sus posibilidades. Se observa de forma esquemática qué fallos son los más codiciados y utilizados.

Hoy, la mayor amenaza se encuentra en el navegador. Sus vulnerabilidades y las de los plugins que exponen al exterior, permiten a los atacantes ejecutar código en el sistema con solo visitar una web. Los exploits packs son los encargados de recopilar esos fallos, crear exploits y "servirlos" a la víctima según su perfil. A cada usuario se le buscará la vulnerabilidad adecuada que explotar, y el payload que lanzar. Con este esquema se mueven las grandes mafias desde hace años, alquilando o distribuyendo estos exploits kits para esparcir su malware.

En la tabla se analizan unos 50 exploits kits (contando las diferentes versiones de un mismo kit) que se han conocido desde 2011 a 2013. Observamos así a primera vista ya diferencias entre algunos. Si bien BlackHole es de los más reconocidos y prolíficos, no es el que contiene un mayor número de exploits en su arsenal. Unos 6 u 8 (es complicado ser exactos puesto que el usuario del kit puede añadir a su gusto). Sin sorpresas, todas las vulnerabilidades están destinadas a Java. La última que se le conoce es la CVE-2013-0431 que afecta a 7u11. El otro exploit kit por excelencia, el Cool Pack, es el que más exploits contiene. Quizás 20. 8 de Java, 4 de Internet Explorer y 2 contra Adobe PDF reader (incluyendo el 10).

La vulnerabilidad reciente más "famosa" entre los kits, presente en más de 20, es CVE-2012-1723. De esta vulnerabilidad ya hemos hablado en una-al-día (en la que se llegó a afirmar con la intención de llamar la atención sobre el grave problema que suponía: "Si no actualizas Java, estás infectado". Se hizo extremadamente popular en 2012 y fue prácticamente el pistoletazo de salida para el calvario de Java, una especie de ensañamiento de los atacantes contra esta tecnología. Se trataba de un fallo de diseño, no una vulnerabilidad en la máquina virtual. Fue solucionada el 12 de junio de 2012.

Otras muy populares son: CVE-2011-3544 (Java Rhino), CVE-2012-1723 (Java Byte / verifier) y CVE2012-5076 (Java-wx). En general, si observamos la panorámica de la tabla y tenemos en cuenta que las celdas de color amarillo fluorescente se corresponden con vulnerabilidades de Java, podemos hacernos una idea de su popularidad en los exploits en los últimos tiempos. A partir de 2006 en adelante, (quizás hasta 2010) las más populares atentaban contra Internet Explorer 6 (azul) y Adobe Reader (rosa)

Otro software muy atacado es Internet Explorer en sí. CVE-2012-1889, CVE-2012-4792, y CVE-2012-4969 son recientes y bastante populares, y afectan a las versiones 8 y 9. Esto es menos rentable para los atacantes, puesto que depende mucho del sistema operativo y su explotación suele ser más compleja. Pero siguen usándola cuando no funcionan otras.

Si nos remontamos a vulnerabilidades más antiguas, tenemos que durante 2010, fue tremendamente popular CVE-2010-0188 que afectaba a Adobe Reader. Aunque sigue siendo objetivo de atacantes, rectificaciones en sus políticas y mejoras de seguridad han calmado el problema. Más allá todavía, sorprenden vulnerabilidades clásicas de Microsoft que todavía se siguen usando como CVE-2006-0003 (MDAC) que afectaba a Internet Explorer 6.

Conclusiones

Con los profesionales distribuyendo malware a través de medios profesionales a su vez (como lo son estos kits de explotación) es muy útil saber qué balas están usando contra las víctimas. Sabemos que durante 2012 el 50% de las infecciones por malware vinieron a través de la explotación de vulnerabilidades en el plugin de Java, y esta recopilación no hace más que confirmar cómo y por qué.

Aunque el usuario debe preocuparse de todas las vulnerabilidades, es necesario priorizar y comprender cuáles elevan realmente el riesgo y cuáles hacen asumibles ese peligro. Está claro que con cierto software, las probabilidades se disparan y es necesario vigilarlo de cerca.

Más información:

ExploitPackTable_2013




Sergio de los Santos
Twitter: @ssantosv

jueves, 25 de abril de 2013

Salto de restricciones en routers Netgear WNDR4700

Una vulnerabilidad en el firmware de los routers Netgear WNDR4700 podría permitir eludir restricciones de seguridad con solo visitar uno de sus recursos web.

Una nueva vulnerabilidad en los routes Netgear ha sido publicada. Al igual que ocurriera hace unas semanas con los modelos WNDR1000, se ha encontrado un fallo de seguridad en los routers Netgear WNDR4700 que podría permitir a un atacante acceder al panel de administración del dispositivo eludiendo el sistema de autenticación.

El problema de seguridad, descubierto por Jacob Holcomb de Independent Security Evaluators, se debe a un error en la interfaz web al procesar solicitudes de
BRS_03B_haveBackupFile_fileRestore.html. De forma que aprovechar la vulnerabilidad resulta muy sencillo: basta con visitar esa página para que el dispositivo deje de solicitar credenciales para acceder al panel de administración:

http://<direccion_IP_del_router>/BRS_03B_haveBackupFile_fileRestore.html

Los efectos de esta vulnerabilidad son permanentes, aunque el dispositivo sea reiniciado. Necesitándose resetear la configuración para restaurar los valores de fábrica.

Para aprovechar la vulnerabilidad es necesario estar conectado al dispositivo, normalmente en red local. Sin embargo si la opción de administración remota (desactivada por defecto) se encuentra activa, esta podría ser explotable desde Internet (WAN).

La vulnerabilidad ha sido comprobada en la versión v1.0.0.34 del firmware del router Netgear WNDR4700, y por el momento no existe ninguna actualización que la solvente. Otras versiones y modelos también podrían verse afectados.

Más información:

Taking over the Netgear WNDR4700

Salto de restricciones en routers Netgear WNR1000
  

Juan José Ruiz

miércoles, 24 de abril de 2013

Vulnerabilidades en McAfee ePolicy Orchestrator

McAfee ha publicado un boletín que soluciona varios problemas de seguridad en su producto ePolicy Orchestrator y que podrían comprometer la confidencialidad, integridad y disponibilidad del sistema afectado.

McAfee ePolicy Orchestrator, también conocido como McAfee ePo, es una consola de administración que permite la gestión centralizada de la seguridad para sistemas, redes, datos y soluciones de cumplimiento de normativas.

Estos problemas de seguridad afectan a ePo 4.5.x y 4.6.x y se deben a versiones vulnerables de OpenSSL y Java incluidas en este software.

Las vulnerabilidades (algunas no ofrecen muchos detalles) son las siguientes:


  • CVE-2013-0169: un error en los protocolos TLS y DTLS al no considerar correctamente los posibles ataques de tiempo en la comprobación del MAC (Message authentication code) al procesar el relleno CBC mal formado. Esto podría permitir a un atacante remoto revelar información sensible a través del envío de paquetes especialmente manipulados y un análisis estadístico de tiempos. Este problema es común en la implementación de OpenSSL y muchos otros programas.
        
  • CVE-2013-1484: un error en el componente Libraries de Java JRE podría comprometer la confidencialidad, integridad y disponibilidad del sistema afectado de forma remota.
        
  • CVE-2013-1485: otro error en el componente Libraries podría afectar a la integridad del sistema.

Se encuentran disponibles las versiones de 4.6.6, y 5.0 que solventan las vulnerabilidades anteriores. McAfee ePolicy Orchestrator 4.5.7, que será lanzada a mediados de mayo, también solucionará estás vulnerabilidades.

Más información:

McAfee Security Bulletin SB10041 - ePO update fixes two vulnerabilities

McAfee ePolicy Orchestrator Multiple Vulnerabilities


Juan José Ruiz

martes, 23 de abril de 2013

Múltiples CSRF en router D-Link DIR865L

Jacob Holcomb ha descubierto múltiples problemas de seguridad en el router wireless D-Link DIR865L que podrían permitir a un atacante remoto realizar ataques cross-site request forgery (CSRF).

CSRF es una técnica que permite realizar peticiones HTTP a usuarios no autorizados aprovechando la incorrecta (o falta de) validación de dichas peticiones. Para explotar estas vulnerabilidades, el atacante debe engañar a la víctima que ha iniciado sesión en el dispositivo para que visite una página web especialmente manipulada desde la que se realizará la petición HTTP no autorizada y sin conocimiento del usuario legítimo.

Todos los formularios HTML del panel de administración del router D-Link DIR865L son susceptibles de este tipo de ataque.

Jacob Holcomb, analista de seguridad de Independent Security Evaluators, ha publicado una prueba de concepto consistente en dos páginas con las que logra cambiar las credenciales de inicio de sesión del dispositivo afectado y, a continuación, activar el servicio de administración remota, quedando el router bajo el control del atacante.



Para que tenga efecto, la víctima debe tener una sesión abierta con el router mientras navega por cualquier web del atacante.

Las vulnerabilidades han sido reportadas en la versión 1.03 del firmware del router, aunque otras versiones también podrían encontrarse afectadas.

Más información:

Taking over the D-Link DIR865L




Juan José Ruiz

lunes, 22 de abril de 2013

Una demanda contra la política de actualización con Android

La ACLU, la organización de usuarios más importante de Estados Unidos por las libertades civiles, ha realizado una demanda al gobierno en la Comisión Federal de Comercio (FTC, EE.UU) sobre la falta de actualizaciones en general y de seguridad en particular de los móviles Android que usan las principales operadoras de telefonía del país: AT&T, Verizon, Sprint y T-Mobile.

La ACLU insta tanto a operadores como a Google para que se dispongan las actualizaciones oportunas y a tiempo en los móviles usados por las compañías. La demanda expone varios puntos que considera hechos relevantes, como por ejemplo que el 53% de los móviles en Estados Unidos usan Android. También que solo el 2% de los dispositivos en todo el mundo están en la última versión 4.2.x. Sin embargo la 2.3, que salió en 2011, que está obsoleta y con múltiples vulnerabilidades, todavía se mantiene instalada en el 44% de los dispositivos.

Otras críticas que se hacen es que por ejemplo el navegador por defecto en Android (un vector de ataque normalmente relevante) no se actualiza a través de Play Store, sino que debe hacerlo a través del sistema operativo completo. En el documento se menciona a los sistemas de actualización de Windows y Apple como modelos que funcionan independientemente del operador o fabricante bajo el que operen. Otros estudios y análisis realizados a lo largo de 2012, por ejemplo, el publicado por Duo-Security basado en su herramienta de escaneo de vulnerabilidades X-Ray dio como resultado que más de la mitad de los dispositivos Android analizados (unos 20.000 que instalaron su software) eran vulnerables a algún tipo de ataque. Otro interesante estudio de Kaspersky indicaba que cerca del 30% del malware para Android afecta a las versiones 2.3.6.


Una mala política

La idea es llamar la atención sobre las políticas de seguridad de los terminales, así como la desprotección de los usuarios ante la invasión de malware que están sufriendo los móviles Android. La falta de centralización en las actualizaciones de Google y la dependencia en cada uno de los múltiples fabricantes de smartphones. Aunque Google provee directamente de actualizaciones en cada versión de Android (mediante AOSP, Android Open Source Project) y las pone a disposición de cada fabricante (Samsung, HTC, LG, Sony, Motorola…) e incluso llega a coordinar su despliegue, no todas las distribuyen a tiempo o dejan modelos y/o versiones sin actualizar. Si a esto unimos que muchos operadores ofrecen en sus terminales versiones de Android personalizadas con el branding de la empresa (aplicaciones específicas, configuraciones, limitaciones o bloqueos de contenidos…), añadimos mayor  posibilidad de que no se exista o se retrase la actualización pertinente (aunque exista la oficial "libre" para el modelo desde el propio fabricante).

Por todo ello, sólo aquellos dispositivos libres de fábrica o que han sido modificados con el firmware original del fabricante (no poseen las típicas modificaciones de cada operador) tiene mayores posibilidades de encontrarse actualizados, aunque no los salva de verse afectados, por retrasos en las actualizaciones o simplemente se les deje de dar soporte.

¿Son las vulnerabilidades el problema?

Aunque en alguna ocasión se ha encontrado malware "drive by download" para Android, en el que una web descargaba contenido específico para este dispositivo explotando una vulnerabilidad o disuadiendo al usuario para su descarga, este no es su mayor problema. La inmensa mayoría de las infecciones de Android viene por la instalación consciente de aplicaciones troyanizadas por parte del usuario. El usuario, ya sea de repositorios oficiales o no, requiere de un programa que contiene una funcionalidad oculta que no desea. Este suele ser el vector más usado, y poco o nada tiene que ver con las vulnerabilidades.

Por tanto, si bien mantener el dispositivo actualizado es importante, los atacantes no están aprovechando el terreno de las vulnerabilidades. En estos momentos, el usuario se encontrará más protegido huyendo de la ejecución de programas no reputados, evitando aprobar las peticiones de recursos excesivos por parte de las aplicaciones, y con una política de firma de aplicaciones más restrictiva, que actualizando el sistema.

Aconsejamos en todo caso la aplicación de las actualizaciones que haya disponibles para cada terminal, mediante OTA desde el propio dispositivo (Over-The-Air, mediante WIFI o 3G) o descargables mediante el software oficial de cada fabricante.

Para usuarios más avanzados que no dispongan de actualizaciones oficiales o quieran probar otras versiones de Android, tienen como alternativas firmwares no-oficiales como CyanogenMod o MIUI, basadas en los repositorios oficiales de Android (AOSP) y mantenidas por la comunidad: (http://www.cyanogenmod.org/ y http://en.miui.com/)

Más información:

ACLU Files FTC Complaint Over Android Smartphone Security

FTC Complaint on Smartphone Security

Early Results from X-Ray: Over 50% of Android Devices are Vulnerable

IT Threat Evolution: Q3 2012 - Mobile malware and operating systems:

Why you'll never have the latest version of Android

Android Open Source Project


José Mesa
jmesa@hispasec.com

domingo, 21 de abril de 2013

Vulnerabilidad de Cross-Site Scripting en Novell GroupWise

Se ha anunciado una vulnerabilidad en Novell GroupWise, que podría permitir a atacantes remotos  la construcción de ataques de cross-site scripting.

Novell GroupWise es un software de colaboración con funcionalidades para uso de correo electrónico, calendarios, mensajería instantánea, coordinación de tareas, control de documentación, etc. WebAccess permite el acceso a las funcionalidades de GroupWise a través de un cliente web.

El problema (con CVE-2013-1086) reside en que las entradas a la interfaz WebAccess a través de atributo "onError" no son debidamente depuradas antes de ser devueltas al usuario. Esto permite a usuarios remotos la ejecución arbitraria de código script en el navegador del usuario. Con ello el atacante podría acceder a las cookies (incluyendo las de autenticación) y a información recientemente enviada, además de poder realizar acciones en el sitio haciéndose pasar por la víctima.

La vulnerabilidad se ha confirmado en las versiones 8.03 HP2 (y anteriores) y en las versiones 12.0.1 HP1 (y anteriores). Se recomienda aplicar GroupWise 8.0.3 HP3 o GroupWise 2012 Support Pack 2.

Más información:

Security Vulnerability: GroupWise WebAccess Cross-site Scripting (XSS) Vulnerability in "OnError" Parameter


Antonio Ropero
Twitter: @aropero

sábado, 20 de abril de 2013

Múltiples vulnerabilidades en MySQL

Dentro del boletín de actualizaciones de Oracle (del que ya efectuamos un resumen) se han anunciado un total de 24 vulnerabilidades en el conocido gestor de base de datos MySQL, que podrían permitir a atacantes remotos provocar condiciones de denegación de servicio, así como acceder y modificar datos.

Los CVE asociados a las vulnerabilidades son CVE-2013-1502, CVE-2013-1506, CVE-2013-1511, CVE-2013-1512, CVE-2013-1521, CVE-2013-1523, CVE-2013-1526, CVE-2013-1531, CVE-2013-1532, CVE-2013-1544, CVE-2013-1548, CVE-2013-1552, CVE-2013-1555, CVE-2013-1566, CVE-2013-1567, CVE-2013-1570, CVE-2013-2375, CVE-2013-2376, CVE-2013-2378, CVE-2013-2381, CVE-2013-2389, CVE-2013-2391, CVE-2013-2392 y CVE-2013-2395.

Los fallos residen en los componentes MemCached, Server Install, Server Partition, Server XML, Server Locking, InnoDB, Data Manipulation Language, Server Optimizer, Server Replication, Server Privileges, Information Schema, Server Types, Server y Stored Procedure.

Se ha publicado una actualización como parte del Oracle Critical Patch Update Advisory - April 2013:


Laboratorio Hispasec

viernes, 19 de abril de 2013

Múltiples vulnerabilidades en productos SAP

Varios productos SAP ERP y NetWeaver han sufrido múltiples vulnerabilidades que podrían permitir ejecutar código arbitrario en los sistemas vulnerables.

Los productos afectados y una breve descripción de los fallos:

  • SAP ERP Central Component (ECC) y SAP ERP Industry Solution (IS) for Healthcare: No se comprueban bien las transacciones, lo que puede llevar a eludir la seguridad y que usuarios no autorizados realicen transacciones no permitidas. Se recomienda aplicar la solución SAP Note 1691744 (https://service.sap.com/sap/support/notes/1691744)
       
  • SAP NetWeaver: El componente SAP Basis Communication Services permite ejecutar comandos de shell con los privilegios del usuario SAP. Se ven afectados los productos anteriores a 7.30. Se recomienda aplicar la solución SAP Note 1674132.
    https://service.sap.com/sap/support/notes/1674132
        
  • SAP ERP Manufacturing - Production Planning (SAP PP): Tampoco se comprueban bien las transacciones, lo que puede llevar a eludir la seguridad y que usuarios no autorizados realicen transacciones no permitidas. Se recomienda aplicar la solución SAP Note 1537089.
    https://service.sap.com/sap/support/notes/1537089

Se recomienda aplicar los parches indicados.

Más información:

ESNC-2013-003:

ESNC-2013-002:

ESNC-2013-001:


Laboratorio Hispasec

jueves, 18 de abril de 2013

Curiosidades sobre la botnet vOlk (y II)

Vamos a mostrar algunas curiosidades técnicas de la botnet vOlk, un software de gran "éxito" entre los atacantes de Latinoamérica que está suponiendo un problema para todos los bancos de países como Perú, México, Costa Rica, Chile, Colombia... Vamos a repasar aquí sus principales características y algunos errores.
(Nota: La primera parte de este artículo fue publicada en Curiosidades sobre la botnet vOlk (I))

Fallos en el panel de control

En el panel web de la versión 4.0 de vOlk se descubrieron varias inyecciones SQL. Las han arreglado en cierta manera en la versión 4.0.2, pero han cometido un grave error a la hora de programar las páginas, que permiten obtener todos los datos robados. El fallo es sencillo: no comprueban que la sesión esté activa (que se haya accedido a través de usuario y contraseña al panel), por tanto con conocer las rutas basta. Normalmente estarán en:

Web-Admin/priv8/Controladores/

Dentro existen ficheros que permiten al atacante descargar en formato TXT los datos robados. El script que lo consigue es muy simple. Como se observa en el código no comprueba la sesión, lo que permite a cualquiera descargar los datos robados.


Este error no fue corregido hasta la versión 5.

El cliente

Con respecto al cliente (el "agente infector"), está programado en VB 6. Visual Basic no se considera popularmente un lenguaje "profesional", pero realmente es "cuestión de gustos". El código es sencillo en general, y bastante entendible, puesto que la idea es que el que compra la botnet lo adapte a sus necesidades.

En todo el programa podemos encontrar algunas curiosidades. Por ejemplo, evitan el uso de cadenas explícitas, tanto de URLs como de rutas de archivo o registro. De esta forma, las direcciones URL o las rutas a archivos o zonas del registro nunca están explícitamente escritas. Esto se supone que lo hacen para dificultar el análisis del binario, pero realmente el método que usan para "encriptarlo" (como se llama la función) no es más que una "ofuscación" en hexadecimal. Por supuesto, el atacante puede modificar el código fuente para cambiar la función.


Un aspecto importante que suele usar esta botnet (y muchas otras) es utilizar el user-agent como una especie de "contraseña" en el panel de control. Cuando se realiza la conexión desde el infector, se establece un user-agent concreto (normalmente una cadena aleatoria), en vez del habitual que define el navegador. En el servidor, se comprueba la cadena user-agent. Si no es la que se espera, se entiende que quien visita la página no está infectado, y por tanto, no debería "curiosear" en ella. Así que se le muestra un 404 falso.


Esto permite mantener "escondida" la página a usuarios que no estén infectados (investigadores, analistas, buscadores, etc.).


Otras características del cliente

La versión 4.0.2 en adelante intenta ser más compleja. Descarga diferentes partes del archivo hosts falso desde diferentes dominios. Y separa con ciertas cadenas algunas partes. Estas cadenas las debe añadir el atacante en la parte del servidor. La separación intenta que la infraestructura sea más "resistente", y quizás ofuscar el contenido (cosa que no consigue).


Luego, lo que el atacante pondrá en el panel de control será algo parecido a esto:

nxnxQ2XXiw99jhX0iwCVl2fu1.2.3.4 banco.com

Esta nueva versión también intenta escribir en %appdata%, un zona en la que podrá conseguirlo si se trata tanto de Windows XP como Vista en adelante.

Por último, intenta evitar la ejecución en ciertos equipos según el nombre del sistema. Esta es la última lista que contiene de serie. Si el equipo tiene ese nombre de red, el troyano no funcionará.


(Nota: La primera parte de este artículo fue publicada en Curiosidades sobre la botnet vOlk (I))


Sergio de los Santos
Twitter: @ssantosv

miércoles, 17 de abril de 2013

Nuevo boletín de seguridad de Oracle corrige 128 vulnerabilidades

En el boletín de abril recientemente publicado, Oracle corrige 128 vulnerabilidades relacionadas sobre todo con sus productos empresariales como Database, Fusion Middleware, PeopleSoft, Siebel... aunque también se ven afectados MySQL y Solaris entre otros, cubriendo 13 familias de productos en total.

Resumimos el número de vulnerabilidades reportadas por familia:

  • 4 para Oracle Database Server, siendo la más importante CVE-2013-1534, relacionada con ejecución remota de código (con un CVSS 10.0).
  • 29 para Oracle Fusion Middleware, con otra ejecución remota de código en JRockit (CVE-2013-2380), relacionada con Java.
  • 6 para Oracle E-Business Suite.
  • 3 para Oracle Supply Chain Products Suite.
  • 11 para Oracle PeopleSoft Products.
  • 8 para Oracle Siebel CRM.
  • 3 para Oracle Industry Applications.
  • 18 para Oracle Financial Services Software.
  • 2 para Oracle Primavera Products Suite.
  • 16 para Oracle y Sun Systems Products Suite, entre ellas Solaris.
  • 2 para Oracle Sun Middleware Products.
  • 25 para Oracle MySQL, en su mayoría denegaciones de servicio.
  • 1 para Oracle Support Tools.

Este boletín se complementa con el publicado conjuntamente para la máquina virtual Java (JRE y JDK), donde se corregían 42 vulnerabilidades.

Las versiones de las respectivas familias afectadas, serían:

  • Database:
    Oracle Database 11g Release 2, versiones 11.2.0.2, 11.2.0.3
    Oracle Database 11g Release 1, versión 11.1.0.7
    Oracle Database 10g Release 2, versiones 10.2.0.4, 10.2.0.5
    Oracle Application Express, versiones anteriores a 4.2.1 
  • E-Business Suite:
    Oracle E-Business Suite Release 12i, versiones 12.0.6, 12.1.1, 12.1.2, 12.1.3
    Oracle E-Business Suite Release 11i, versión 11.5.10.2 
  • Fusion Middleware:
    Oracle Containers for J2EE, versión 10.1.3.5
    Oracle COREid Access, versión 10.1.4.3
    Oracle GoldenGate Veridata, versión 3.0.0.11
    Oracle HTTP Server, versiones 10.1.3.5.0, 11.1.1.5.0, 11.1.1.6.0
    Oracle JRockit, versiones R27.7.4, R28.2.6 y posteriores
    Oracle Outside In Technology, versiones 8.3.7, 8.4.0
    Oracle WebCenter Capture, versión 10.1.3.5.1
    Oracle WebCenter Content, versiones 10.1.3.5.1, 11.1.1.6.0
    Oracle WebCenter Interaction, versiones 6.5.1, 10.3.3.0
    Oracle WebCenter Sites, versiones 7.6.2, 11.1.1.6.0, 11.1.1.6.1
    Oracle WebLogic Server, versiones 10.0.2, 10.3.5, 10.3.6, 12.1.1
    Oracle Web Services Manager, versión 11.1.1.6 
  • Health Sciences:
    Oracle Clinical Remote Data Capture Option, versiones 4.6.0, 4.6.6 
  • Oracle FLEXCUBE:
    Oracle FLEXCUBE Direct Banking, versiones 2.8.0 a 12.0.1 
  • Oracle MySQL Product Suite:
    Oracle MySQL Server, versiones 5.1, 5.5, 5.6 
  • Oracle Support Tools:
     Oracle Automatic Service Request, versiones anteriores a 4.3.2 
  • PeopleSoft:
    Oracle PeopleSoft HRMS, versión 9.1
    Oracle PeopleSoft PeopleTools, versiones 8.51, 8.52 y 8.53 
  • Primavera:
    Primavera P6 Enterprise Project Portfolio Management, versiones 7.0, 8.1, 8.2 
  • Retail:
    Oracle Retail Central Office, versiones 13.1, 13.2, 13.3, 13.4
    Oracle Retail Integration Bus, versiones 13.0, 13.1, 13.2 
  • Siebel:
    Oracle Siebel CRM, versiones 8.1.1, 8.2.2 
  • Supply Chain:
    Oracle Agile EDM, versiones 6.1.1.0, 6.1.2.0, 6.1.2.2
    Oracle Transportation Management, versiones 5.5.05, 6.2

Para más información sobre las vulnerabilidades solucionadas y la aplicación de los parches, se recomienda visitar urgentemente el sitio oficial del boletín.

Más información:

Oracle Critical Patch Update Advisory - April 2013



José Mesa Orihuela

martes, 16 de abril de 2013

Java corrige 42 vulnerabilidades y mejora un poco sus opciones de seguridad

Oracle corre una carrera de obstáculos para corregir y mejorar su plugin de Java. En la última actualización de seguridad, corrige 42 fallos, la mayoría críticos. Introduce algunas mejoras en los mensajes de advertencia y opciones, y continúa el soporte para la rama 6, que dijo que abandonaría el febrero.

Se acaba de publicar Java 7u21 y Java 6u45. Además de la cantidad de vulnerabilidades corregidas, se mejoran los mensajes de seguridad y se eliminan algunas opciones de seguridad peligrosas, inútiles y activadas por defecto. Hasta ahora, y como avisamos hace algunas semanas, los mensajes de que un applet se encontraba firmado o autofirmado no se diferenciaban mucho. Parece que han trabajado en eso... pero no demasiado.

Para empezar, han eliminado la opción "Baja" de la configuración de seguridad (la famosa palanquita) cosa se vaticinó como inútil. Permitía la ejecución de los applets no firmados de forma automática en el sistema sin preguntar.


Los mensajes sobre applets firmados cambian ligeramente, pero no demasiado. Muestra la URL por completo al Jar y cambia el mensaje de recordar la selección.


Tampoco cambian demasiado los mensajes sobre applets autofirmados.


Si el applet no está firmado, sí que cambia un poco el mensaje:


Algo interesante es que han eliminado la inútil opción sobre la que ya advertimos "Permitir otorgamiento de acceso elevado a aplicaciones autofirmadas", que venía activada por defecto y que hacía que en la práctica un applet autofirmado se comportase como uno firmado. Pero siguen sin activar de manera predeterminada la opción de comprobar los certificados revocados o desactivar una versión anticuada de la rama 6 si la encuentra en el equipo mientras instala la 7 (al menos recordárselo al usuario).


Por lo que en realidad no ha cambiado demasiado estéticamente, y un poco su funcionalidad. Al menos, se ve que están trabajando en el asunto intensamente, y en cada nueva versión intentan mejorar. Desde enero, los cambios son notables, pero insuficientes. Los mensajes no son la solución. El bloqueo absoluto por defecto de los applets no firmados, y un sistema de actualización obligatorio y automático (también por defecto), entre otras medidas, será la única forma de proteger al usuario.

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)

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

una-al-dia (03/02/2013) Mejorar y entender la seguridad del plugin de Java (IV)

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


Sergio de los Santos
Twitter: @ssantosv

lunes, 15 de abril de 2013

Curiosidades sobre la botnet vOlk (I)

Vamos a mostrar algunas curiosidades técnicas de la botnet vOlk, un software de gran "éxito" entre los atacantes de Latinoamérica que está suponiendo un problema para todos los bancos de países como Perú, México, Costa Rica, Chile, Colombia... Muchos ya la han estudiado, pero vamos a repasar aquí sus principales características y algunos errores.

vOlk es una "suite" para crear una botnet. Como muchas otras que operan en Latinoamérica, se compone principalmente de su panel de control en PHP y MySQL, que se colgará en alguna web (comprometida o no) y desde el que se darán órdenes a los clientes. Los clientes son el segundo componente. En el caso de vOlk se trata de un sencillo programa programado en Visual Basic 6 y que infecta a los usuarios. El programa se configura para recibir órdenes del panel de control, se compila, y se distribuye entre las víctimas.

La botnet vOlk apareció hace unos tres años, ha conseguido mucha popularidad y está pensada principalmente para ser un troyano bancario sencillo basado en el pharming (cambio de hosts). Esta simple técnica, que se utiliza desde hace muchos años, sigue siendo efectiva. Requiere de pocas habilidades por parte del atacante y de una infraestructura básica. Solo con eso se pueden obtener importantes beneficios.

El panel de control

Explicando el panel de control, también se explican sus funcionalidades. Para instalarlo se proporciona un fichero de configuración SQL que contiene algunas tablas y su valor por defecto. El de la imagen corresponde a última versión, 5.


La versión inmediatamente anterior, se veía así:


Luego se copian los ficheros PHP en Apache y se "instala". El proceso solo requiere del establecimiento de un usuario y contraseña para controlar la botnet.

En la pantalla inicial se detallan sus características. Con las diferentes versiones, se añadieron cambios estéticos en el panel, pero sobre todo en el código. Se corrigieron algunas vulnerabilidades pero se mantienen otras. Principalmente, sus habilidades son las de cambiar dinámicamente el archivo hosts de Windows en las víctimas, de descargar un ejecutable y lanzarlo, de hacer que visiten de forma "invisible" o visible un enlace, de robar contraseñas de Messenger, Internet Explorer y Filezilla y de proporcionar cómodas estadísticas de "éxito" para el atacante. En ellas contiene una pequeña base de datos de GeoIP para localizar a las víctimas por países. Por ejemplo, en la versión 4, si elegimos que nos muestre las víctimas de países "desconoSidos" (sic).


Vías de negocio

La principal vía de negocio está pensada para realizar pharming. El atacante genera una copia de la web del banco y la cuelga en una dirección IP. Luego establece el archivo hosts de la víctima para que apunte a esa IP. El usuario, no se dará cuenta de que es una página falsa e introducirá sus datos. En esta página falsa del supuesto banco, habrá pequeños scripts PHP como este para enviar las contraseñas robadas del formulario por correo, guardarlas en un fichero TXT en el servidor, o ambas opciones. Normalmente también almacenan la dirección IP desde donde ha picado la víctima y luego redirigen al banco real una vez completada la estafa.




Sergio de los Santos
Twitter: @ssantosv