Poodle, un nuevo golpe al modelo de seguridad SSL

Tres investigadores de Google han descubierto recientemente un bug en el protocolo de criptografía SSL 3.0 (SSLv3 – Secure Sockets Layer). El bug, conocido como Poodle (CVE-2014-3566) podría ser utilizado por alguien externo para interceptar datos. Estos datos supuestamente deberían estar encriptados por el protocolo HTTPS durante la comunicación entre los usuarios y los servicios webs a los que acceden.

Según los investigadores, no es una vulnerabilidad en la implementación de los protocolos SSL/TLS, sino una vulnerabilidad en el diseño del protocolo SSLv3 a la hora de utilizar bloques cifrados. Tampoco es un defecto en el modelo clave pública/privada utilizado por los certificados SSL, por lo que los usuarios con certificados instalados en sus servidores no tendrán que reemplazarlos.

Se cree que el bug no es un fallo tan grave como Heartbleed, que afectó a OpenSSL y se detectó en abril de este año. En el fallo Poodle, los atacantes necesitan tener una posición de privilegio en la red para poder hacer el exploit. Sin embargo, la utilización extendida de Hotspots o wifis públicas si que hacen este ataque un problema real.

Tanto los usuarios como los administradores de servidores tienen que realizar cambios en sus equipos de tal forma que no se utilice el protocolo SSLv3 en las comunicaciones.

Usuario final

El usuario debe comprobar que el protocolo SSL 3.0 está deshabilitado en su navegador. En este enlace se puede ver como desactivar el protocolo SSLv3 en distintos navegadores.

Firefox ya ha comunicado que en próximas versiones desactivará la utilización de este protocolo:

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

Por último recomendamos que estemos atentos durante estos días a la recepción de correos de phising que nos soliciten cambiar nuestras credenciales. En ningún caso deberemos acceder a estos sitios web falsos que intentarán conseguir nuestros datos de acceso.

Administradores de Servidores

En estas web podremos consultar si nuestro servicio es vulnerable o no a Poodle:

https://www.tinfoilsecurity.com/poodle

https://www.ssllabs.com/ssltest/index.html

A continuación indicamos como solucionar el bug Poodle en diferentes entornos:

RedHat/CentOS

Si administramos un servidor con sistema operativo RedHat/CentOS, desde RedHat ya se ha publicado una versión actualizada del software OpenSSL. Esta actualización realmente no soluciona el bug, sino que utiliza la opción TLS_FALLBACK_SCSV, un mecanismo que previene a los atacantes a forzar a los navegadores a utilizar SSL 3.0.

Para actualizar OpenSSL ejecutaremos:

yum update openssl

Más información: wiki.centos.org/Security/POODLE

 

Windows

Poodle está presente en todas las versiones de windows 2003, 2008 y 2012, independientemente de si tenemos una versión 32 o 64bit. La solución a adoptar es deshabilitar los protocolos SSL v2.0 y v3.0.

Este cambio se deber hacer modificando el registro, lo cual se debe hacer con cuidado. En este enlace de Microsoft se indica como hacer este cambio:  http://support.microsoft.com/kb/187498.

Una vez realizado el cambio, deberemos reiniciar nuestro servidor para que los cambios se confirmen.

 

Apache

En el caso de que administremos un servidor web, probablemente utilicemos un servidor Apache con mod_ssl, editaremos el fichero de configuración correspondiente deshabilitando los protocolos SSLv3:

  1. Opción 1: deshabilitar SSLv2 y SSLv3 (habilitar todo menos SSLv2 y SSLv3):
    SSLProtocol All -SSLv2 -SSLv3
  2. Opción 2: deshabilitar todo excepto TLSv1. Indicaremos una de estas dos líneas según la versión de RedHat/CentOS que tengamos. Normalmente será la segunda línea de las que indicamos a continuación:
    SSLProtocol -All +TLSv1 +TLSv1.1 +TLSv1.2
    SSLProtocol -All +TLSv1

Una vez hechos los cambios reiniciaremos el servicio apache. En un servidor CentOS, el fichero de configuración de mod_ssl se encuentra en /etc/httpd/conf.d/ssl.conf

Más información: https://access.redhat.com/solutions/1232413

 

Nginx

Otro servidor web que va ganando adeptos es Nginx. Si queremos proteger nuestro servidor web Nginx frente a Poodle tendremos que hacer una configuración similar a Apache, deshabilitando el protocolo SSLv3:

ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;  # don’t use SSLv3 ref: POODLE

cPanel

cPanel es un panel de gestión que nos permite administrar de forma completa nuestro servidor mediante un entorno web. Si tenemos un servidor cPanel, seguramente utilicemos como servidor web Apache, como servidor POP3/IMAP Dovecot y como servidor SMTP Exim. A continuación indicamos como proteger a nuestro servidor para estos tres elementos:

Apache (HTTP/HTTPS):

  1. Accedemos al administrador WHM / Service Configuration / Apache Configuration / Include Editor / Pre Main Include.
  2. Elegimos como versión, todas las versiones
  3. Añadimos el siguiente código en la caja de texto que aparece:
    SSLHonorCipherOrder On
    SSLProtocol -All +TLSv1
  4. Pulsamos el botón de actualizar para reiniciar el servidor Apache.

 

Dovecot (POP3/IMAP):

  1. Accedemos al administrador WHM / Service Configuration / Mailserver Configuration
  2. Cambiamos la casilla nombrada como SSL Cipher List a:
    ALL:-SSLv3:RC4:-SSLv2:!ADH:+HIGH:+MEDIUM:-LOW:-EXP

Exim (SMTP):

  1. Accedemos al administrador WHM / Service Configuration / Exim Configuration Manager / Advanced Editor
  2. Cambiamos la casilla nombrada como tls_require_ciphers a:
    ALL:-SSLv3:RC4:-SSLv2:!ADH:+HIGH:+MEDIUM:-LOW:-EXP

Otras plataformas

RedHat ha publicado diferentes páginas donde se indica como proteger nuestros servidores frente a la vulnerabilidad Poodle:

  1. Tomcat/Jboss: https://access.redhat.com/solutions/1232233
  2. vsftpd: https://access.redhat.com/solutions/1234773
  3. Otros servicios: https://access.redhat.com/articles/1232123

 

¿Eres de Shakespeare o de Cervantes?

Shakespeare o Cervantes - Registra dominio .es

¿Eres de Shakespeare o de Cervantes? ¿Eres de los del Té a las cinco o de las Tapitas en el bar?

Registra tu dominio .es por 4,99 € *

* Precios sólo aplicable al primer año. Precios no incluyen IVA.

Descubierta vulneralidad Bash (GNU/Linux/Unix) – Shellshock

Bash es el interprete de comandos de la mayoria de sistemas GNU/Linux/Unix. La vulnerabilidad, denominada CVE-2014-6271 (Shellshock), ha sido descubierta por Stéphane Chazelas, y permite la ejecución de código malicioso, con lo que se podría conseguir el control del sistema.

bash-500x375

El error se encuentra en como Bash trabaja con las variables de entorno, y permite la ejecución de cualquier código añadiendolo al final de una línea de ejecución Bash dentro de las variables de entorno.

La mayoría de servidores web LAMP ejecutan PHP como CGI (normalmente mediante FCGI o FastCGI). Dependiendo de la configuración del servidor, las páginas PHP en modo CGI se ejecutan a través del intérprete Bash. De este modo, esta vulnerabilidad pone en riesgo la seguridad del sistema que aloja tus páginas web, p0r lo que recomendamos la actualización urgente de tu interprete Bash desactualizado.

¿Cómo detectar si mi servidor es vulnerable?

Para detectar si tu servidor tiene una versión de bash vulnerable a este fallo de seguridad, puedes conectarte a tu servidor por SSH y ejecutar:

env x='() { :;}; echo Vulnerable' bash -c /bin/true

Si es vulnerable la salida estándar de este comando te devolverá la palabra ‘Vulnerable’

Si no es vulnerable no te devolverá nada.

¿Cómo resolver la vulnerabilidad Shellshock?

Muchas distribuciones de Linux como Ubuntu, Red Hat y CentOS ya disponen de parches que impiden la ejecución de código después del final de una función Bash.

En caso de tener que actualizar el bash de tu servidor Cloud con sistema Red Hat/CentOS es necesario escribir el siguiente comando en el sistema:

yum update bash

En caso de tener que actualizar el bash de tu servidor Cloud con Ubuntu o Debian 7 es necesario escribir el siguiente comando en el sistema:

sudo apt-get update && sudo apt-get upgrade bash

Si tu servidor tiene instalada una distribución Debian 6, es necesario añadir un repositorio adicional a tu fichero /etc/apt/sources.list y ejecutar el comando de Ubuntu/Debian 7:

  • Editar el archivo /etc/apt/sources.list
  • Agregar la siguiente linea al final del fichero: deb http://ftp.us.debian.org/debian squeeze-lts main non-free contrib
  • Una vez agregado el repositorio ejecutar sudo apt-get update && sudo apt-get upgrade bash
  • Borrar la línea agregada al fichero /etc/apt/sources.list

Momentos históricos de Internet

Actualmente vemos como algo normal enviar un tweet , subir un video a Youtube, hablar por Skype, etc… En más de una ocasión te habrás podido preguntar ¿Cuál fue el primer video que se subió a Youtube? o ¿qué contenía el primer tweet de la historia? En este artículo vamos a tratar de responder a todas esas curiosas cuestiones y hablaremos de alguno de los hechos históricos de Internet.

 

El primer correo electrónico

En 1961 se mostró en el Instituto Tecnológico de Massachusetts (MIT – Massachusetts Institute of Technology) un sistema primitivo de comunicación electrónica entre dos terminales. Pero no fue hasta 1971 cuando Ray Tomlison integró la arroba (@) como signo de separación entre el usuario y la máquina,  enviándose así mismo un mensaje de prueba que según su biografía lo único que contenía era la palabra QWERTYUIOP.

tomlinson-2

La primera imagen en la Web

Tim Berners-Lee, conocido por ser el padre de la Web, subió a la red una foto del grupo de música “Les Horribles Cernettes” que le había enviado un compañero del CERN (Conseil Européen pour la Recherche Nucléaire). Les Horribles Cernettes se podría considerar el primer grupo de música que apareció en la red.

Les_Horribles_Cernettes_in_1992

El primer video de Youtube

El 23 de Abril del 2005 se subió un pequeño video en el portal de Youtube donde se mostraba Jawed Karim, uno de los fundadores de Youtube, en un zoo. El video con título “Me at the Zoo” es considerado el primer video de Youtube.

Imagen de previsualización de YouTube

 

El primer tweet

Twitter comenzó a funcionar en 2005 bajo el nombre de Twttr, el primer tweet que se escribió fue a manos de su fundador Jack Dorsey para inaugurar la red social, Jack twitteo “Just setting up my twttr” (Ajustando mi twttr).

0df5659c-6a0d-40f4-a790-a862546497ee_12-620x292

El primer artículo vendido a través de Ebay

El primer artículo que se vendió a través de Ebay fue un puntero laser roto, vendido a un coleccionista en 1995 por 14,83 dólares.

El primer banner

Para terminar os hablaremos del primer banner en la historia de las páginas web. El primer banner vino de manos de Joe McCambley patrocinado por la empresa de telecomunicaciones AT&T en 1994, únicamente aparecía un fondo negro con las siguientes palabras en blanco: Have you ever cliked your mouse right here? You will  (Alguna vez has clikeado con tu ratón aquí? Lo harás)

021cdddc-a07d-4ce7-9bf0-bed499e35af1_6-620x79

Los 10 dominios más caros de la historia

La especulación con los dominios surgió en los años 90 con el funcionamiento del sistema de nombres de dominio, por aquel entonces pocas eran las personas que imaginarían que el precio de un dominio podría llegar a costar millones en un futuro. Un visionario fue Chris Clark, quien compró el dominio pizza.com en 1994 por 20 dólares y en 2008 lo vendió por 2,6 millones de dólares.

A continuación repasaremos los dominios más caros de la historia, en muchas ocasiones el precio de la venta de un dominio incluye el posicionamiento en la red y el negocio asociado al dominio.


1. Insurance.com

En el año 2010 el dominio insurance.com se vendió por 35,6 millones de dólares. A la hora de comprarlo también se pagó por el contenido de la web, y actualmente es el buscador de seguros más usado en Estados Unidos.

2. Vacationrentals.com

En el año 2007 este dominio se vendió por 35 millones de dólares. El comprador fue Brian Sharples, el cual declaró que la única razón por la que había comprado el dominio vacationrentals.com era para que su competidor, Expedia, no se hiciera con él.

3. Privatejet.com

Atlanta Nations Luxury Transportation pagó por este dominio 30,18 millones de dólares en el año 2012.

4. Internet.com

QuinStreet compró el dominio internet.com por 18 millones de dólares, aunque la compra del dominio traía consigo buena parte del negocio de WebMediaBrands.

5. Insure.com

De nuevo aparece QuinStreet como el comprador del dominio insure.com, quien pago 16 millones de dólares y al igual que insurance.com, también propiedad de QuinStreet,  funciona como un buscador de seguros.

6. Sex.com

Los dominios con contenido para adultos también se abren paso en la lista de dominios más caros de la historia, por el dominio sex.com se pagaron 13 millones de dólares en el año 2010.

7. Hotels.com

En el año 2001 se pagaron 11 millones de dólares por el dominio hotels.com, si accedemos desde España nos redireccionará a hoteles.com

8. Fund.com

En el año 2008 se pagaron cerca de 10 millones de dólares por el dominio fund.com, actualmente al acceder al sitio web muestra el siguiente mensaje: “Please come back later to check FUND.com”.

9. Porn.com

En 2007 se pagaron 9,5 millones de doláres para hacerse con el dominio porn.com que conteniene la palabra clave más utilizada para buscar pornografía en Internet.

10. Fb.com

Para proteger su marca registrada Facebook pagó 8,5 millones de dólares en 2010.  El dominio redirige a la página de Facebook.


Está claro que registrar un dominio por unos pocos euros y que después podamos venderlo por millones es algo muy complicado, pero la aparición de nuevas extensiones puede ayudar y animar a los usuarios a intentarlo.

Bienvenido al blog de nerion

Empresa de servicios cloud, hosting y registro de dominios. Trust us, we take care of you!.
Suscripción a nerion
Siguenos en Twitter Siguenos en Facebook Siguenos en Linkedin Siguenos en YouTube Siguenos en Flickr Siguenos en Foursquare
Entradas antiguas por mes
Twitter
nerion en Facebook