Archivo

Posts Tagged ‘java’

Tener instalado Java 6 puede ser peligroso

agosto 29, 2013 Los comentarios están cerrados

javammOracle dio por finalizado el soporte público para Java versión 6 el pasado febrero. Las versiones públicas de Java poseen un soporte de tres años. Pasado ese tiempo solo los clientes que tengan una licencia comercial del producto podrán tener acceso a los parches críticos, periodo que se extiende cinco años adicionales.
Tener instalado Java 6 puede ser peligroso
¿Cual es el problema? Java 6 aun se encuentra instalado en millones de sistemas, no tiene soporte y existe una vulnerabilidad (CVE-2013-2463) con exploit publicado que se está usando activamente para infectar equipos y no hay ni va a haber parche para Java 6. Al menos para la gran mayoría de usuarios.

Esto significa que mantener una versión de Java 7 sin actualizar o tener Java 6 en el sistema y visitar una página infectada significa el compromiso del sistema.

Web oficial de descarga Java: http://www.java.com/es/download/

Fuente: Seguridadpc.net, Hispasec

Categorías:Noticias, Vulnerabilidades Etiquetas: ,

¿Tienes Java 6 instalado? (Actualiza!)

agosto 29, 2013 Los comentarios están cerrados

Oracle dio por finalizado el soporte público para Java versión 6 el pasado febrero. Las versiones públicas de Java poseen un soporte de tres años. Pasado ese tiempo solo los clientes que tengan una licencia comercial del producto podrán tener acceso a los parches críticos, periodo que se extiende cinco años adicionales.

¿Cual es el problema? Java 6 aun se encuentra instalado en millones de sistemas, no tiene soporte y existe una vulnerabilidad con exploit publicado que se está usando activamente para infectar equipos.

Leer más…

Los productos Microsoft ya no aparecen en el Top10 de inseguros [Kaspersky]

noviembre 9, 2012 Los comentarios están cerrados

Los productos de Microsoft ya no figuran en la lista de Kaspersky de los 10 más inseguros debido a sus vulnerabilidades. La política de actualizaciones automáticas llevada a cabo por la compañía en las últimas versiones de sus sistemas operativos están dando sus frutos.

En la lista de Kaspersky, Oracle Java ocupa el primer y segundo lugar, con advertencias de “Altamente crítico” y “Extremadamente crítico” respectivamente. Encontramos después a Adobe Flash en las posiciones tercera y cuarta. Otro producto de Adobe, Acrobat y su Reader, ocupa la quinta plaza.

La sexta y séptima posición están ocupadas por productos de Apple, QuickTime y iTunes, con vulnerabilidades calificadas como altamente críticas. La octava posición está ocupada por Winamp. Cierran la lista productos de Adobe nuevamente: Adobe Shockwave Player y el reproductor de Adobe Flash.

Hace unos años Microsoft habría terminado la lista, pero a partir del lanzamiento de Windows Vista, la compañía cambió su política con las actualizaciones automáticas. Windows 7 se basa en eso y en Windows 8 se ha dado un paso más. También es cierto que la compañía de seguridad VUPEN ha encontrado la primera vulnerabilidad 0-day en Windows 8 e Internet Explorer 10.

Destacar del informe de Kaspersky que el 28% de ataques a dispositivos móviles fueron dirigidos contra Android 2.3.6. En el tercer trimestre del año, el 56% de exploits aprovecharon vulnerabilidades de Java y, atentos: 91,9 millones de URLs sirven código maligno, con un incremento del 3% respecto del segundo trimestre.

Viendo estas cifras, dan ganas de no tener Java en el equipo, salvo que sea absolutamente imprescindible. Ya que no se puede evitar que haya por ahí personajes empeñados en amargar la vida del usuario, es muy importante disponer siempre del software más actualizado.

Fuente: Genbeta | Segu-Info

Grave vulnerabilidad sin parche en Java está siendo aprovechada por atacantes

agosto 29, 2012 Deja un comentario
Se ha descubierto una vulnerabilidad en Java para la que no existe parche, que está siendo aprovechada por atacantes y cuyo código es público. Es el peor escenario posible.
Todavía no se sabe mucho sobre la vulnerabilidad, puesto que no ha dado tiempo a realizar un estudio exhaustivo, pero lo divulgado por ahora nos sitúa en el peor escenario posible.
FireEye descubría un servidor con un .jar que aprovechaba una vulnerabilidad. Por tanto, alguien la conoce y está aprovechando el fallo. A través de un dominio de tercer nivel dinámico (aa24.net) y un servidor de correo web de una compañía china (que probablemente haya sido atacada), se está (todavía) distribuyendo malware gracias a ese fallo en Java.
A través de un índice en la carpeta “meeting” del servidor, muy ofuscado con Javascript, el malware que se está distribuyendo es este:
y

El problema afecta a la última versión de Java en su rama 7, hasta su “update 6“. No afecta a la rama 6, que todavía se mantiene pero que se encuentra en periodo de “extinción“. Funciona sobre los principales navegadores e incluso con EMET activo.

A pesar de que los investigadores que lo descubrieron no ofrecieron detalles, un tercero ha publicado una prueba de concepto para explotar el fallo, con lo que se abría la puerta a que cualquiera pudiera explotarla. El código es sencillo, limpio, funcional y fiable. Compilar y lanzar. Poco después, se ha introducido como módulo en Metasploit. Esto licencia a que cualquier atacante pueda comenzar a distribuir su propio malware (muy probablemente durante los próximos días se pueda ver en Blackhole, el kit de explotación de moda entre los atacantes). Si, como ya hemos mencionado en más de una ocasión, una máquina virtual de Java no actualizada es lo que más aprovechan los creadores de malware para distribuir sus muestras, esta vulnerabilidad permite “abrir el mercado” también entre los actualizados.
Extracto del código del .Jar
En ausencia de un parche eficaz, no existe una forma sencilla de mitigar el problema. Lo más recomendable es deshabilitar Java del navegador. No se sabe cuándo solucionará Oracle el problema. Su ciclo cuatrimestral de actualizaciones, sugiere que hasta el 16 de octubre puede que no parcheen el gravísimo problema. Desde luego, Oracle no suele publicar parches fuera de ciclo. En contadas ocasiones lo ha hecho con su base de datos, su producto estrella. Pero menos aún con Java desde que le pertenece.
En abril de 2010 Tavis Ormandy y Rubén Santamarta descubrieron un grave fallo de seguridad en JRE. A Ormandy le dijeron desde Oracle que no lo consideraban tan grave como para publicar nada antes del periodo establecido. Una semana después, publicaban un parche fuera de ciclo (Java 6 Update 20), que no acreditaba la corrección de la vulnerabilidad. Tuvieron que comprobar que, simplemente, el fallo dejaba de darse, pero no había confirmación oficial.
Hace algunas semanas escribíamos en una-al-día, un titular que (obviamente tomándonos ciertas licencias) afirmaba “Si no actualizas Java, estás infectado“. Pretendía llamar la atención sobre el hecho de que una enorme parte de los atacantes estaban aprovechando de forma masiva fallos muy recientes en Java y que la manera más eficaz de defenderse era actualizar. Lo estamos viviendo día a día en el laboratorio. Ahora podemos añadir que, incluso si se está actualizado y con medidas extra de seguridad como EMET, se corre el riesgo de que un atacante ejecute código en el sistema.
Más información:
Zero-Day Season is Not Over Yet
Java 7 0-Day vulnerability information and mitigation.
Java Deployment Toolkit Performs Insufficient Validation of Parameters
[0DAY] JAVA Web Start Arbitrary command-line injection – “-XXaltjvm” arbitrary dll loading
Sun About Face: Out-of-Cycle Java Update Patches Critical Flaw
Sergio de los Santos
Twitter: @ssantosv
Fuente: Hispasec

Si no actualizas Java, estás infectado

agosto 8, 2012 Deja un comentario
Los applets de Java, unidos a una máquina virtual JRE vulnerable, son hoy por hoy la combinación perfecta para que los atacantes infecten a sus víctimas. No importa qué hábitos se sigan en el sistema: no tener actualizado JRE, es garantía de infección. Veamos por qué y cómo protegerse.
En nuestro laboratorio realizamos habitualmente análisis forenses a máquinas infectadas con troyanos bancarios. Así podemos detectar el binario, aislarlo y estudiar su comportamiento.
De esta manera comprobamos cómo y con qué se infecta la gente ahí fuera, en el mundo real donde el malware limpia las cuentas bancarias de los usuarios (una media de 3.000 euros por robo).
Entre otros descubrimientos, en los últimos meses,  hemos comprobado que en el 100% de los análisis realizados (y no han sido pocos) la razón de la infección con troyanos bancarios era una máquina virtual Java desactualizada. En concreto dos vulnerabilidades (aunque también otras más antiguas):

 

Cómo suele funcionar el exploit
La víctima visita cualquier web. Cualquiera: desde páginas pornográficas hasta webs de ganchillo (ejemplos reales). No importa el navegador. De forma más o menos transparente (según el navegador) se carga el applet que explota la vulnerabilidad. El usuario quedará infectado. Una curiosidad es que el código Java se encargará de descargar “a trozos” un ejecutable que ensambla en local. También, que el ejecutable será “único” para la víctima. Aunque su funcionalidad sea la de intentar robar las credenciales del banco, su “hash” o firma será diferente en cada caso, y no funcionará en otra máquina que no sea la que ha infectado. Una especie de poliformismo del lado del servidor pero “en tiempo de ensamblado en local“.
Por si fuera poco, el malware no necesita de privilegios de administrador para funcionar. Se instala en %appdata%, dentro de un directorio con nombres aleatorios donde suele tener permisos de escritura, y se asegura la supervivencia posicionándose en la rama del registro del usuario CurrenVersion\Run donde también puede escribir.
¿Qué hace mal Oracle?
Oracle no es un buen ejemplo en el campo de la gestión de seguridad. Sun tampoco lo era (la compró en abril de 2009). Por ejemplo, tuvimos que esperar a finales de 2008 para que Sun hiciera algo muy simple: desinstalar las versiones vulnerables cuando un usuario se actualizaba. Sí, dejaban en el sistema la versión vulnerable dentro de la misma rama.
Pero el problema es que en cierta medida, Oracle sigue haciéndolo. Si bien dentro de la misma rama se borran las anteriores… no se eliminan, ni se actualizan, ramas anteriores. Muchos usuarios se encuentran en este momento con dos ramas de JRE en su sistema. La 6 (que va por su update 33), y la 7 (que va por su update 5). Conservar alguna anterior es más que arriesgado. Por ejemplo si con la rama 6 update 18 (arcaica) el usuario decide instalar la última versión 7 update 5 desde la web oficial, se encontrará con esto:
No solo no se elimina la rama 6, sino que tampoco se actualiza de la 18 a la última 33. Ni siquiera advierte del peligro de mantener esa rama. Y lo que es peor… los dos serán accesibles para el atacante desde el navegador.
Oracle tampoco se ha pasado a la “autoactualización“, a la que se ha visto obligada Adobe con su Flash recientemente. Primero permitía a los usuarios que se actualizasen libremente. Luego mejoró, con  un mensaje claro cuando aparecía una nueva versión (y en este estadio se encuentra Oracle). Pero más tarde se ha visto obligado a actualizar, sí o sí por defecto, y despreocupar al usuario. Oracle no quiere hacer eso. Tiene pánico a que los diferentes programas no funcionen en sus muchas ramas (todavía actualiza la rama 1.4).
Tal es el problema, que Firefox, Chrome e incluso Safari, bloquean las versiones antiguas de Java, para evitar más infecciones.
Protección
Las medidas de protección son las de siempre… más alguna otra. Por ejemplo, son varios los profesionales como Brian Krebs o Larry Seltzer que directamente aconsejan desinstalar Java por completo. Ambos alegan que no se echará de menos. Esto es discutible y depende del perfil de cada usuario. Pero sí es cierto que, al menos, se debe evitar que sea accesible desde el navegador. Existen varias páginas que ofrecen instrucciones para deshabilitarlo (independientemente del navegador) para Windows y Mac.
Otros métodos de protección incluyen, según el navegador, evitar los applets en páginas desconocidas, o directamente evitar el JavaScript selectivamente.
Más información:
Don’t Need Java? Junk It.
Java (por fin) eliminará las versiones antiguas al actualizar
How to protect yourself from Java-based malware
Ditching Java might be a good move
A Month Without Java: The Results
Sergio de los Santos
Twitter: @ssantosv
Fuente: Hispasec