Seguridad

Vulnerabilidad Crítica en WordPress que afecta a 10 millones de sitios web

Actualización de Seguridad - WordPress 4.0.1

Ha sido detectada una vulnerabilidad crítica en WordPress que afecta principalmente a la versión 3 del sistema de gestión de contenidos. La empresa que ha localizado la vulnerabilidad, Klikki Oy, alerta que está activa hasta la versión 3.9.2. Según las estadísticas de WordPresss, alrededor de un 86% de los sitios web con WordPress utilizan una versión vulnerable. Se estima que el número total de WordPress instalados a día de hoy supera los 10 millones.

La vulnerabilidad se ha encontrado activa en los últimos 4 años, en concreto desde el lanzamiento de la versión 3.0 de WordPress. La versión 4.0. liberada en Septiembre de este año, no es vulnerable.

¿En qué consiste la vulnerabilidad?

Para aprovecharse del error, el atacante sólo necesita que exista un campo de texto, tal como el formulario de introducción de comentarios que se encuentra habilitado por defecto.

De esta forma el atacante podría aprovechar esta vulnerabilidad mediante la introducción de comentarios sin la necesidad de loguearse como administrador. El código inyectado en forma de comentario podría ser ejecutado por el navegador web del administrador al leerlo. Es en ese momento cuando el código se activa y comienza a realizar operaciones con permisos administrador. Estas operaciones incluyen acciones tales como: cambio de contraseña de la cuenta administrador, creación de nuevas cuentas, y en el caso más grave puede afectar al servidor inyectando código PHP en él.

Os recomendamos encarecidamente que actualicéis vuestro WordPress a esta última versión estable, ya que además de introducir mejoras y nuevas funcionalidades, se corrigen fallos de seguridad como éste. Así mismo si utilizáis otros CMS también es recomendable estar al día de las actualizaciones estables.

Aspectos Técnicos

Una función desconocida del archivo wp-includes/formatting.php del componente Comment Handler es afectada por esta vulnerabilidad. El problema ocurre en una función de manipulación de texto llamada wptexturize(), que habitualmente es ejecutada para cada comentario y otros bloques de texto. La función reemplaza ciertos caracteres con entidades utilizadas en HTML. Por ejemplo, los símbolos de comillas rectas son reemplazadas por comillas en cursiva (unicode 8220 y 8221 respectivamente). El problema está en que la manipulación no se hace de forma correcta causando un agujero de seguridad de clase cross site scripting. Concretamente la vulnerabilidad se encuentra en esta parte del código:

$textarr = preg_split('/(<.*>|[.*])/Us', $text, -1, PREG_SPLIT_DELIM_CAPTURE);

Una actualización a la versión 4.0.1 elimina esta vulnerabilidad. Para aquellos que no puedan realizar una actualización de la versión de WordPress, por ejemplo por incompatiblidad en el tema o plugins instalados, ha sido publicada inmediatamente después de descubrir esta brecha de seguridad. La vulnerabilidad se tratará con las siguientes líneas de código:

function wptexturize($text) {
    return $text; // ADD THIS LINE
    global $wp_cockneyreplace;

Más información técnica del exploit: http://klikki.fi/adv/wordpress.html

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

 

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

¿Servidor Cloud o Hosting Compartido?

¿Qué necesito contratar para que mi aplicación web funcione sin problemas, un servidor cloud o un plan de hosting compartido? ¿Qué me sale mejor en relación calidad/precio? Estas pueden ser las preguntas que se formulan las personas que vayan a comenzar a trabajar en la red ya sea para montar un CMS, una aplicación web, una tienda virtual, etc…En este artículo analizaremos y compararemos ambos servicios e intentaremos responder a estas preguntas.

cloud - hosting

Para realizar una comparación de ambos servicios deberemos comenzar con el análisis de las siguientes características:

  • Rendimiento
  • Límites
  • Gestión
  • Precio

Rendimiento

Hay que tener en cuenta que si comparamos en rendimiento un servidor cloud con uno compartido, el servidor dedicado responderá con mayor velocidad a las peticiones de los usuarios. Esto no significa  que las características del servidor compartido sean menores que las del servidor cloud, pero obviamente en el servidor compartido no seremos los únicos que vayamos a utilizar los recursos de la máquina y esto podría provocar una respuesta más baja que la que nos podría proporcionar el servidor dedicado.

Entonces, ¿Debo de contratar un servidor cloud para que funcione bien mi página web?

No, si acabas de empezar con tu negocio o página y no esperas tener muchas visitas al principio, lo más fácil y económico es que contrates un hosting en un servidor compartido. El servidor cloud estaría pensado para aplicaciones que consuman más recursos, como por ejemplo Magento o para páginas que tengan un alto número de visitas al día.

Si necesitamos un rendimiento alto nos veremos obligados a contratar un servidor cloud ya que en el podemos optimizar los recursos como nosotros queramos y sabremos que nadie más los va a usar.

Límites

Las limitaciones que nos encontraremos en un servidor compartido serán mayores que en un servidor cloud.

Por ejemplo, los planes de alojamiento compartido tienen un límite de transferencias que si se rebasa podría traer como consecuencia un recargo en la factura del servicio contratado, en un servidor cloud los límites de transferencia son más elevados.

Otras de las limitaciones a tener en cuenta serían las de espacio en disco, aunque los planes de hosting pueden llegar a tener la misma cuota de disco que un servidor cloud. En nerion se adaptan las cuotas de espacio a las necesidades de cada cliente.

Gestión

Los alojamientos compartidos son gestionados por la propia empresa del hosting, pero se le concede al usuario un panel donde puede gestionar de forma bastante sencilla e intuitiva su sitio.

Por el contrario, los servidores cloud suelen ser administrados por los propios usuarios y es necesario tener experiencia para configurar correctamente los diferentes sitios o aplicaciones web que se vayan a alojar en él. En el caso de nerion, se pueden contratar servidores cloud administrados por nosotros con un límite de horas al mes de servicio administrado.

Precio

Obviamente el plan de alojamiento compartido va a ser más barato que el servidor cloud.

Hay que tener en cuenta que si esperas ganar dinero con tu negocio en Internet hace falta una inversión para que todo funcione correctamente, si no la haces podrías estar perdiendo clientes potenciales que decidan comprar en la competencia únicamente por la velocidad de respuesta de la página.

¿Qué es la Deep Web?

La Deep Web, también conocida como “Internet profunda” o “Internet invisible”, son los sitios de internet que los motores de búsqueda no pueden indexar o rastrear.  Se estima que el 96% del contenido que hay internet se encuentra en la Deep Web, y el 4% restante sería el que podríamos encontrar gracias a Google u otros portales de búsqueda.

Para acceder a una página que no se encuentra indexada hay que saber la ruta o dirección exacta de ese sitio en concreto.

¿Porqué una página se encuentra en la Deep Web?

Existen varias razones por la cual cualquier archivo o sitio web no se encuentre indexado o rastreado por los motores de búsqueda y acaben en la Deep Web:

  • Páginas que varían según el tipo de consultas o por la información proporcionada por el usuario
  • Contenido que se encuentra en sitios donde no es posible la indexación por los motores de búsqueda.
  • Páginas que se encuentran protegidas por contraseñas
  • Sitios que se encuentran protegidos por mecanismos de tipo Captcha
  • Contenido accesible mediante código de tipo Javascript, Flash u otro tipo de lenguaje de programación similar.

Deep-Web

¿Cómo se puede acceder?

Hay diferentes programas o software que te permite el ingreso a la red profunda,  pero el más conocido es TOR (The Onion Router) que proporciona un navegador para la Deep Web.

TOR proporciona una red de túneles virtuales que permite a  los usuarios navegar por internet de forma anónima, ayuda a reducir o evitar el seguimiento que hacen los sitios web de los hábitos de navegación de las personas y a publicar sitios web y otros servicios sin la necesidad de revelar su localización. Aunque TOR tiene como objetivo el de proteger a los usuarios de la vigilancia en Internet, también ha proporcionado una manera de ocultar servicios de dudosa legalidad.

TorLogo

Para poder encontrar información se ha trabajado en crear buscadores para la internet profunda, aunque la forma más eficaz es utilizando buscadores sobre temas específicos. Algunos ejemplos son los siguientes:

  • Scirus, que se usa para hacer búsquedas específicamente para información científica.
  • Infomine, que se usa para buscar material escolar de todo tipo.
  • FreeLunch, que se usa para buscar datos económicos.
  • CompletePlanet, que abarca diversos temas.
  • Search Engine Guide, que te puede ayudar a encontrar un buscador adecuado al tema que estés investigando. Se puede decir que es un buscador de buscadores.
  • Archive, que es un punto inicial si no tienes muy claro el tema de tu búsqueda.

¿Qué nos podemos encontrar en la Deep Web?

La posibilidad de crear y navegar de forma anónima ha permitido el desarrollo de diferentes actividades delictivas como pueden ser: venta de drogas, tráfico de información clasificada,  lavado de dinero, armas, pornografía infantil, entrenamiento especializado en temas delictivos, contratación de asesinos a sueldo…Se podría decir que Deep Web es el mercado negro más grande que se puede encontrar en la red, este tipo de transacciones se están llevando a cabo a través de la moneda digital BitCoin, ya que las transacciones del BitCoin son entre un usuario y otro, es decir no se encuentra respaldada por ningún gobierno o banco central.

Algunas organizaciones como WikiLeaks o Anonymous han operado y se han organizado usando la Deep Web.

Esto ha provocado que algunos gobiernos estén intentando bloquear el acceso a la Deep Web, como es el caso de gobierno de Etiopía donde están probando diferentes mecanismos de seguridad para prohibir el acceso a la Deep Web, aunque todavía no se conocen el éxito de estas operaciones. Otras organizaciones gubernamentales como es el caso de la Agencia Nacional de Seguridad (NSA) están utilizando la Deep Web para realizar contraespionaje intentando encontrar documentos secretos de enemigos potenciales.

Para terminar me gustaría reflexionar sobre el uso de la Deep Web ya que es cierto que puede ser utilizada para temas delictivos, pero también ha permitido que los ciudadanos hayan podido continuar comunicándose cuando gobiernos totalitarios han restringido las comunicaciones y el uso de TOR se ha incrementado a raíz de los escándalos de espionaje realizados por parte de la NSA.

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