Tag: Java

Oracle Abril 2016 – 136 vulnerabilidades

Oracle Critical Patch Update Advisory – April 2016

Oracle corrige 136 vulnerabilidades en su actualización de seguridad de abril

Siguiendo su ritmo de publicación trimestral de actualizaciones, Oracle publica su boletín de seguridad de abril. Contiene parches para 136 nuevas vulnerabilidades diferentes en múltiples productos pertenecientes a diferentes familias, que van desde el popular gestor de base de datos Oracle Database hasta Solaris, Java o MySQL.

Los fallos se dan en varios componentes de los productos:

  • Oracle Database Server, versiones 11.2.0.4, 12.1.0.1 y 12.1.0.2
  • Oracle API Gateway, versiones 11.1.2.3.0 y 11.1.2.4.0
  • Oracle BI Publisher, versión 12.2.1.0.0
  • Oracle Business Intelligence Enterprise Edition, versiones 11.1.1.7.0,
    11.1.1.9.0 y 12.2.1.0.0
  • Oracle Exalogic Infrastructure, versiones 1.0 y 2.0
  • Oracle GlassFish Server, versión 2.1.1
  • Oracle HTTP Server, versiones 12.1.2.0 y 12.1.3.0
  • Oracle iPlanet Web Proxy Server, versión 4.0

(continua leyendo…)


CERTs: 30 vulnerabilidades más reportadas

Image Courtesy of Stuart Miles at FreeDigitalPhotos

Sistemas Afectados

Todos aquellos sin parches de actualización de Adobe, Microsoft, Oracle, or OpenSSL.

Alcance

Los cibercriminales continúan explotando vulnerabilidades detectadas en programas de cómputo que no han sido actualizados con los parches de seguridad correspondientes, esto con la finalidad de realizar atques contra infraestructura crítica de organizaciones.

Por lo menos el 85% de estos ataques pueden ser prevenidos [1](link is external).

Esta alerta provee información de las 30 vulnerabilidades mas utilizadas para realizar esto ataques, acompañada de recomendaciones de prevención y mitigación de los riesgos.

La información está basada en un análisis completado por el Canadian Cyber Incident Response Centre (CCIRC, Centro Canadiense de Respuesta a Ciberincidentes) y desarrollado en colaboración con otros CERTs de Canadá, Nueva Zelanda, Reino Unido y el Centro de Ciberseguridad de Australia.

Impacto

Una intrusión exitosa en la red puede provocar impactos serios, particularmente si aquello que sea comprometido se hace público y a su vez, es expuesta información sensible. Los posibles daños incluyen:

  • Perdida temporal o permanente de información sensible o propietaria
  • Interrupción de operaciones,
  • Perdidas financieras relacionada con los costos de reestablecer sistemas y archivos, y
  • Daño potencial y reputacional a la organización

Solución

  • Actualización al día de software
  • Establecer procesos robustos para la aplicación de parches

(continua leyendo…)


La seguridad en Java sigue siendo un desastre

La seguridad en Java sigue siendo un desastre. Además de los últimos 0-day y actualizaciones (al menos parece que sacan rápido nuevas correcciones), se ha encontrado un applet firmado con un certificado robado. Este applet no aprovecha una vulnerabilidad, sino que el hecho de estar firmado le permite comprometer el equipo. Además, en este caso concreto, la configuración de Java por defecto demasiado relajada, ayuda al atacante.

Malware Domain List anunció en Twitter que había encontrado un Jar que descargaba archivos maliciosos, incluso en la última versión conocida.

La primera impresión, por supuesto, fue la de encontrarse ante un nuevo 0-day. Teniendo en cuenta los últimos acontecimientos y que el año pasado la mitad de las infecciones vinieron por Java, era lo más lógico.

Por cierto, el último episodio (encontrado el día 28 siendo explotado y arreglado muy recientemente) se diferenciaba sustancialmente de los fallos anteriores. Este aprovechaba una vulnerabilidad en la propia máquina virtual, no un problema de escapada de la “sandbox”, como se ha venido haciendo últimamente. Pero no, este Jar no aprovechaba ningún fallo.

Había sido descargado de un sitio comprometido que, por supuesto, habían convertido en un punto de infección con un Exploit Kit. Lo “interesante” de este Jar es que no aprovecha nada extraño, solo que está firmado.

Como ya mencionados en la serie dedicada a Java hace unas semanas, los applets firmados son como ejecutables en los que confía el sistema totalmente.

Han firmado el applet con un certificado robado de una empresa que existe. Aunque a la víctima le aparece un mensaje, no es extraño que (continua leyendo…)


Primero Twitter, ahora Facebook

No pasaron siquiera dos semanas para que los usuarios afectados por el incidente a los servidores de Twitter tuvieran que reflexionar acerca de la seguridad de los sistemas de información de los proveedores de redes sociales y por ende, acerca de la información que a través de ellas comparten, y de nuevo hoy tienen que reflexionar en lo mismo:

¿qué tan segura es la red social que utilizo?

Esta pausa obligada que invita a la reflexión surge porque hoy Facebook avisa a todos sus usuarios que han sido víctimas de un problema de seguridad derivado (desde mi perspectiva de una incorrecta práctica de seguridad informática al interior de Facebook) de visitar a uno de sus proveedores de apps en donde las laptops del equipo de Facebook fueron contaminadas con un virus.

Como consecuencia del contagio se generó la vulnerabilidad de tener un ataque de 0-day misma que, como indica Facebook, fue corregida a tiempo y por ende la afectación no llegó a más.

¿Cómo se traduce? en que a diferencia de Twitter, la versión de Facebook indica que (continua leyendo…)


Twitter bloqueado, Twitter hackeado

Hoy por la tarde a mediodía, una persona cercana a mi intentó enviar un DM a un amigo en Twitter… Para ello utilizaba en su smartphone una app distinta a la que está instalada en forma nativa, desafortunadamente para él fue imposible ya que  la respuesta recibida era un mensaje que indicaba errores en la conexión con el servidor.

Un poco más tarde conocimos el motivo, en esta ocasión no fue culpa del 3G ofrecido por su compañía telefónica, la razón proviene de una acción tanto reactiva como preventiva realizada por Twitter Inc: resetear las contraseñas de 250,000 usuarios.

¿Por qué acción reactiva y preventiva?

En el mundo de la seguridad informática existen dos conceptos importantes: prevención (que siempre será la mejor) y la reacción (que indica que no hubo prevención de riesgos y que además el riesgo sucedió).
Twitter Inc, de acuerdo a lo publicado en su blog, comunica que detectaron un ataque de intrusión, mismo que lograron contener y detener; sin embargo en el recuento de los daños se identificó que hubo vulneración en las bases de datos y se logró filtrar información de autenticación de los usuarios.

Ante el incidente de seguridad, la Prevención se orientó a evitar la afectación a usuarios: se resetearon no sólo las contraseñas sino los tokens de apps ligadas a las cuentas de Twitter

No se enojen con Twitter, mejor vamos a lo que sigue, los consejos:

1. Sino funciona tu twitter, tu contraseña fue reseteada, tendrás que esperar el email de Twitter para la reactivación (¡cuidado con el phishing!)
2. Si tu twitter sí funciona, previene: cambia tu contraseña
3. Usa contraseñas largas, seguras y únicas
4. Evita utilizar muchas apps ligadas a tu cuenta de Twitter y otras redes sociales
5. Revisa el tema de Java en tus navegadores, desactívalo para minimizar riesgos en tus dispositivos

A continuación, el post de Twitter Inc

Keeping our users secure

Friday, February 01, 2013

As you may have read, there’s been a recent uptick in large-scale security attacks aimed at U.S. technology and media companies. Within the last two weeks, the New York Times and Wall Street Journal have chronicled breaches of their systems, and Apple and Mozilla have turned off Java by default in their browsers.This week, we detected unusual access patterns that led to us identifying unauthorized access attempts to Twitter user data. We discovered one live attack and were able to shut it down in process moments later. However, our investigation has thus far indicated that the attackers may have had access to limited user information – usernames, email addresses, session tokens and encrypted/salted versions of passwords – for approximately 250,000 users.As a precautionary security measure, we have reset passwords and revoked session tokens for these accounts. If your account was one of them, you will have recently received (or will shortly) an email from us at the address associated with your Twitter account notifying you that you will need to create a new password. Your old password will not work when you try to log in to Twitter.Though only a very small percentage of our users were potentially affected by this attack, we encourage all users to take this opportunity to ensure that they are following good password hygiene, on Twitter and elsewhere on the Internet. Make sure you use a strong password – at least 10 (but more is better) characters and a mixture of upper- and lowercase letters, numbers, and symbols – that you are not using for any other accounts or sites. Using the same password for multiple online accounts significantly increases your odds of being compromised. If you are not using good password hygiene, take a moment now to change your Twitter passwords. For more information about making your Twitter and other Internet accounts more secure, read our Help Center documentation or the FTC’s guide on passwords.We also echo the advisory from the U.S. Department of Homeland Security and security experts to encourage users to disable Java on their computers in their browsers. For instructions on how to disable Java, read this recent Slate article.This attack was not the work of amateurs, and we do not believe it was an isolated incident. The attackers were extremely sophisticated, and we believe other companies and organizations have also been recently similarly attacked. For that reason we felt that it was important to publicize this attack while we still gather information, and we are helping government and federal law enforcement in their effort to find and prosecute these attackers to make the Internet safer for all users.

Updated 4:47pm: Corrected detail on disabling Java in penultimate paragraph.

Posted by Bob Lord (@boblord)
Director of Information Security

 


Open ID en riesgo

Fuente: Hispasec
Autor: Javier Rascón

Se ha descubierto un fallo en la extensión ‘Attribute Exchange’ de OpenID que podría permitir a un atacante remoto modificar la información que es intercambiada entre las partes encargadas de la autenticación.

OpenID es un estándar de identificación digital descentralizado que permite a sus usuarios utilizar una única cuenta para poder acceder a diferentes sitios. Con esto se obtiene un mejor control de los datos asociados a la cuenta, ya que se encuentran en un único punto. Además es el proveedor del ID quien se encarga de identificar al usuario, evitando así que la contraseña sea gestionada por los diferentes sitios a los que se desea acceder.

El fallo se encuentra en los proveedores de OpenID que utilizaban ‘OpenID4Java’, que no verificaba si la información pasada a través de Attribute Exchange estaba firmada o no. Esto podría ser aprovechado por un atacante remoto modificar la información que es intercambiada entre las distintas partes que se comunican, con lo que la información que sólo es confiada al proveedor de identidad puede ser comprometida.

Los descubridores de la vulnerabilidad, Rui Wang, Shuo Chen y Xiao Feng Wang, se pusieron en contacto con todos los sitios afectados por dicho problema, quienes ya han emitido sus respectivos parches de seguridad.

Más información:

Attribute Exchange Security Alert
http://openid.net/2011/05/05/attribute-exchange-security-alert/

Image: luigi diamanti / FreeDigitalPhotos.net


Derecho Informático - IT Lawyers. Siempre solicite la autorización del autor para reproducir los contenidos de este blog.
iDream theme by Templates Next | Powered by WordPress