Según leíamos en Hispasec hace unos días (se nos pasó por aquello de las fechas), se han detectado varias vulnerabilidades que afectan a la popular aplicación de mensajería del sistema operativo Android, las cuales pueden comprometer la seguridad del aparato atacado. En concreto son:

1. Es posible cambiar el estado de un usuario simplemente proporcionando el número de teléfono registrado en WhatsApp y el texto con el mensaje del nuevo estado ya que no se requiere ninguna autenticación o autorización previa a dicha acción.

2. La función que comprueba el código que se envía durante el proceso de registro de un nuevo número de teléfono es vulnerable a ataques de fuerza bruta, lo cual podría permitir que un atacante remoto registre de números de teléfono arbitrarios y suplante la identidad de estos usuarios.

3. El tráfico de datos a través del protocolo XMPP de WhatsApp no está cifrado, lo cual podría ser aprovechado por un atacante remoto para llevar a cabo un ataque Man-in-the-Middle, y conseguir leer, enviar, recibir, e incluso modificar mensajes que están destinados a otra persona.

Solamente se ha facilitado como medida de protección ante el segundo fallo, una limitación de 10 intentos para introducir el códigoque se envía a la hora de realizar el ataque de fuerza bruta, aunque no hay nada al respecto de las otras dos vulnerabilidades. Recordemos que esta aplicación informática se ha hecho muy popular entre todos los usuarios de teléfonos móviles que disponen de Android como su sistema operativo, lo cual multiplica exponencialmente el número de usuarios que pueden verse afectados. Mas información aquí.

Compartir

De todos es sabido que una configuración correcta de PHP hablando de servidores web es vital para evitar “sustos” o ataques hacia nuestras máquinas. Si eres un administrador de sistemas o estás interesado en estas cuestiones, os recomendamos leer (en Inglés) estos 25 ejemplos para mejorar la seguridad de instalaciones en las que se ejecute PHP.

Acceso a; “25 PHP Security Best Practices For SysAdmins“

Compartir

Un ataque coordinado que empezó el lunes pasado ha inundado muchas cuentas de la conocida red social Facebook con imagenes de violencia extrema o videos porno. Se ha apuntado la posibilidad de que se trate de una acción de 4Chan/B, aunque hay que señala a Anonymous como responsables de la misma. Hasta el momento no ha habido ninguna reivindicación.

El ataque se aprovecha de la novedad de incluir los timelines de los usuarios de Facebook a los que seguimos, con lo que nuevamente surgen dudas y comentarios acerca de la seguridad y privacidad dentro de la red social. Los responsables de la misma están trabajando en contener la situación y en averiguar la autoría de este desagradable incidente. Verificad vuestras cuentas y borrad del muro estas imágenes si habéis sido una de las muchas víctimas y ojo con los enlaces externos, además de revisar vuestras opciones de privacidad.

Compartir

Apple informa a través de su lista de correo de actualizaciones de seguridad de gran impacto para el sistema en Java caso de ser explotadas. Están disponibles para Mac OS X 10.6, 10.7 y 10.8 (también para la versión server).

Dichas actualizaciones,se pueden obtener directamente a través del menú “Actualizacione de softwware”, solventan un posible ataque a través de applets de Java maliciosos debidamente manipulados, con el fin de ser explotados por sitios webs preparados tal fin. Pudiendo derivar en la ejecución arbitraria de código con los privilegios del usuario en el sistema afectado.

Compartir

Se ha hecho público ahora un incidente que tuvo lugar en los años 2007 y 2008, en el cual, unos ciberatacantes al parecer procedentes de China, se hicieron con el control de los satélites estadounidenses  Landstat-7 y Terra AM-1 en al menos cuatro ocasiones, los cuales son utilizados para conocer datos del terreno y de su clima, si bien no hicieron uso alguno de ellos, limitándose simplemente a “apoderarse” de ellos. No se puede afirmar que el gobierno chino esté detrás de este suceso.

Ambos satélites, son dirigidos desde la estación noruega de Svalbard y mediante estos ataques, de entre aproximadamente dos y doce minutos de duración, tuvieron acceso también a todos los archivos que estos manejan. Estos datos han salido a la luz mediante un informe de la Comisión de Revisión de Economía y Seguridad entre EEUU y China.

Compartir

Según leemos en Hack Players, la web de MySQL ha sido víctima de un ataque  cuyo resultado, a falta de más datos sobre los contenidos que aloja, es la posible infección por malware de quienes lo visiten. Es la segunda vez este año que mysql.com sufre un ataque (no ponemos el enlace ya que ahora mismo, no es seguro visitar su web). En Slashdot se ha publicado que vendieron el exploit por 3.000 $.

Se trata de un “iframe” ofuscado en su código, que realiza una redirección a un servidor localizado en Alemania, para acto seguido, llevar al visitante a otro servidor desde donde se ejecuta un exploit. Recomendamos extremar las precauciones si se ha visitado recientemente y realizar un análisis del equipo en busca de posibles rastros de malware.

Compartir

Se está hablando mucho estos días del bug y el cambio de passwords en Lion tal y como podemos leer en Ontinet y nos han llegado varias consultas sobre cómo actuar hasta que Apple publique una actualización que lo solvente.

Aclaramos en el título lo de “un ataque local”, ya que se requiere acceso físico a la máquina para poder llegar a efectuar dicho ataque con sólo tipear el siguiente comando en el terminal; dscl localhost -passwd /Search/Users/NombreUsuario.

Esta vulnerabilidad / debilidad en la gestión de las contraseñas de Mac OS X no es nueva tal y como nos recuerdan desde Genbeta (donde también se dan buenos consejos), ahora, con el lanzamiento de Lion, vuelve a estar de actualidad y es lógica la preocupación de los usuarios de OS X frente a un ataque de este tipo.

Realmente no es algo tan complejo de paliar y obviamente, ayuda que sea un ataque para el que se necesite estar frente al equipo caso de querer efectuarlo. También en LifeHacker (ENG) un usuario ha preguntado lo mismo y vamos a dar un repaso a las medidas a poner en práctica.

Desde el terminal;

• Desactivar los permisos de dscl (como root) tipeando; chmod 100 /usr/bin/dscl

Desde Preferencias del Sistema – Seguridad;

• #Nota. Puedes ver esta imagen de LifeHacker para ver mejor los cambios
• Desactiva el inicio de sesión automático.
• Activa la opción “solicitar password inmediatamente” cuando se active el salvapantallas o la suspensión.
• (Sobre este punto comentar que en Preferencias- Energía podéis bajar el tiempo de esos valores, recomendable).
• Solicitar la contraseña de administrador para desbloquear cualquier preferencia del sistema bloqueada.
• No olvides bloquear el candado en la zona inf izquierda.

Desde Preferencias del Sistema – Usuarios y grupos;

• Desactivar la cuenta de invitado
• (También recomendable en “compartir” desactivar el acceso a carpetas compartidas)

Ahora sólo es cuestión de esperar y ver el “tiempo de respuesta” por parte de Apple para parchear este agujero de seguridad.

Compartir

Si hablamos de certificados digitales, a todos nos viene a la memoria el tan nombrado caso de Diginotar del que ya hemos hablado en Daboweb en varias ocasiones. Si hablamos de un protocolo como “SSL“ (acrónimo de “Secure Sockets Layer“, protocolo de capa de conexión segura), pensaremos en conexiones cifradas, “candados” en la parte superior de la barra de nuestro navegador, en resumen “una conexión segura” ¿o no?.

Hoy os queremos recomendar la lectura de una entrada publicada en el blog de nuestro amigo Sergio Hernando, en la que va más allá del típico resultado que podemos ver en la salida del “scanner” de vulnerabilidades de turno.

Tal y como dice el autor, solemos asociar las conexiones vía “SSL” a aplicaciones web, pero no hay que olvidar por ejemplo el uso masivo que hacemos de “SSL” en la recepción o envio de correo electrónico (aunque hoy en día, seguramente esa conexión ya sería vía “TLS“, una implementación mejorada del protocolo “SSL“), programas de mensajería instantánea, aplicaciones VoIP (voz sobre IP), etc.

Por lo que si hablamos de auditorías de seguridad, todo lo que vaya cifrado bajo “SSL“, debería ser auditado de la forma más minuciosa posible para evitar ataques en los que, la suplantación de identidad, junto a la posible captura de unos datos que “presuntamente” viajan por la red bajo una capa de cifrado, pueden resultar devastadores en los sistemas comprometidos.

Acceso a; “Principios teóricos y prácticos de auditoría SSL“.

Compartir