Un fallo en WordPress permite a un autor borrar ficheros y ejecutar código arbitrario

Los investigadores de RIPS Technologies GmbH descubrieron hace siete meses una vulnerabilidad en el conocido CMS WordPress que permite a un usuario con bajos privilegios poder secuestrar todo el sitio web y ejecutar código arbitrario a nivel del servidor.

A pesar de todo el tiempo transcurrido, en la actualidad todas las versiones de WordPress, incluida la 4.9.6, siguen afectadas por el fallo de seguridad descubierta por los investigadores, que reside en una de las funciones principales de WordPress y se ejecuta en segundo plano cuando un usuario borra de forma permanente una miniatura o una imagen subida.

La función de eliminación de miniaturas acepta entradas de usuario sin sanitizar, permitiendo a usuarios con privilegios restringidos, a partir de los autores, borrar cualquier fichero alojado en el almacenamiento web, algo que solo tendría que poder realizar los administradores del servidor o el sitio web. El requerir al menos una cuenta de autor reduce la gravedad del fallo hasta cierto punto, que puede ser explotado por cualquier colaborador o hacker que obtenga las credenciales de un autor mediante ataque de phishing, reutilización de contraseña u otros tipos de ataques.

Los investigadores avisan de que el actor malicioso podría terminar borrando ficheros críticos como “.httaccess” del servidor web, que contiene ciertas configuraciones relacionadas con la seguridad, en un intento de inhabilitar la protección. Otra posibilidad es borrar el fichero “wp-config.php”, abriendo así al puerta a que se vuelva a iniciar el instalador y poder así reconfigurar el sitio web con los parámetros que el hacker crea conveniente y obtener así control total.

Aquí es importante tener en cuenta una cosa, y es que el hacker no tiene acceso directo al fichero “wp-config.php”, así que no puede obtener parámetros de configuración como el nombre del base de datos, el nombre de usuario de MySQL y la contraseña de dicho usuario de MySQL, por lo que no le queda otra que reconfigurar utilizando un base de datos remota que esté bajo su control. Una vez terminado el proceso de instalación, el atacante podrá hacer lo que quiera con el sitio web, incluso ejecutar código arbitrario.

Los investigadores han publicado un parche propio para corregir este problema, mientras el equipo de seguridad de WordPress todavía busca una manera de parchearlo en la próxima versión de mantenimiento del CMS.

Fuente: The Hacker News

Google Chrome penalizará las webs que no sean HTTPS

Esta nueva interfaz de Chrome ayudará a los usuarios a comprender que no todos los sitios HTTP son seguros.

Google Chrome se ha centrado en la seguridad que ofrecen sus páginas webs y ya penaliza a las páginas que no usan HTTPS en sus resultados de búsqueda. La próxima novedad llegará con la actualización Chrome 68 en julio, con la que intentara disuadirnos de navegar en páginas con HTTP sin cifrar, y empezará a marcar todos los sitios HTTP como “no seguros” en la barra de direcciones.

Si bien Chrome ya nos avisaba cuando utilizábamos una web poco segura, ahora el mensaje aparecerá siempre que dicha web utilice el protocolo HTTP sin cifrar, lo cual afectará a la gran mayoría de páginas de internet, eso si, no tanto a las que visitamos normalmente.

El protocolo HTTPS ha crecido tanto que hoy en día más del 68% del tráfico de Chrome en Android y Windows se hace sobre SSL/TLS. La cifra es tal, que 81 de los 100 sitios web con más tráfico de Internet utilizan HTTPS por defecto.

Esta nueva interfaz de Chrome ayudará a los usuarios a comprender que no todos los sitios HTTP son seguros.

Según publicaba Chromium en su blog, el uso del protocolo seguro de transferencia de hipertexto en la web ha mejorado a medida que han evolucionado los indicadores de seguridad de Chrome. Es por eso que los usuarios deben esperar que una web, por defecto, sea segura. Y como eso debe ser la normalidad, solo deberían recibir avisos cuando haya problemas.

Fuente | CSO ComputerWorld

Están intentando robar las tarjetas de crédito almacenadas en instalaciones de Magento

Los datos almacenados por las tiendas electrónicas se han convertido en algo muy codiciado por hackers y cibercriminales, que buscan debilidades y fallos de seguridad en ese tipo de CMS para hacerse, sobre todo, con los datos de pago y las contraseñas de los usuarios.

Eso es lo que está pasando con Magento, e-commerce que según la empresa de ciberseguridad Sucuri está captando la atención de hackers que intentar robar datos como tarjetas de crédito y credenciales de PayPal. Siendo más concretos, hay un agente que se dedica a infectar sitios web Magento con un ladrón de tarjetas de crédito.

Uno de los métodos empleados por los hackers para conseguir los datos mencionados en el párrafo anterior consiste en añadir código adicional en la instalación del CMS. Los investigadores de Sucuri han descubierto una función sospechosa llamada “patch()” en el fichero “includes/config.php”, que nunca debe ser modificado de forma directa por el usuario por cuestiones de seguridad. Las invocaciones a la mencionada función se dedican a escribir contenido obtenido de fuentes externas en archivos específicos relacionados con el proceso de pago o el control de los usuarios.

/app/code/core/Mage/Payment/Model/Method/Cc.php
/app/code/core/Mage/Payment/Model/Method/Abstract.php
/app/code/core/Mage/Customer/controllers/AccountController.php
/app/code/core/Mage/Customer/controllers/AddressController.php
/app/code/core/Mage/Admin/Model/Session.php
/app/code/core/Mage/Admin/Model/Config.php
/app/code/core/Mage/Checkout/Model/Type/Onepage.php
/app/code/core/Mage/Checkout/Model/Type/Abstract.php

Los atacantes recurren a distintas vías para esconder enlaces externos de forma que no sean fáciles de detectar para las personas que carecen de los conocimientos necesarios. El código malicioso introducido ofusca enlaces externos de manera que una simple decodificación de reemplazo de variables en conjunto con la función base64 puede hacerlos legibles.

Un ejemplo de esto sería lo siguiente. Este es el código legítimo:

$link_a = $link.'YTGgAnrv'

Que pasaría a ser este otro, apuntando a Pastebin:

$link_a = 'hxxp://pastebin[.]com/raw/YTGgAnrv';

Esto quiere decir que el código malicioso ejecutado por el CMS atacado procede de Pastebin, una aplicación web que permite a sus usuarios subir pequeños textos, generalmente ejemplos de código fuente, para que estén visibles al público en general. Los expertos de Sucuri informan que se está usando este método para mantener un perfil bajo en los ataques y hacer su detección más difícil. Para dificultar la detección, los hackers incluyen la invocación “error_reporting(0);” para evitar el reporte de errores y así exponer la infección.

El código alojado en Pastebin forma parte del proceso de robo de información comprometedora como las tarjetas de crédito o las contraseñas de los usuarios, datos que luego son enviados a dominios externos para su procesamiento o venta.

Los expertos de Sucuri recomiendan verificar el fichero “/includes/config.php” lo antes posible, algo a lo que hay sumar la comprobación de otros malware que puedan estar afectando a la instalación de Magento y que pueden incluir puertas traseras.

Fuente | Muy Seguridad

Debian 8 ya se ha quedado sin soporte

Debian 8 ha sido una de las versiones de esta distribución Linux más apreciada por los usuarios y los administradores de sistemas. Esta distro fue lanzada en abril de 2015 y, como las demás versiones, contaba con un soporte de 3 años, soporte que este mismo fin de semana ha llegado ya a su fin, por lo que es urgente que, si seguimos utilizando esta distribución, actualicemos cuanto antes a la versión actual Debian 9.
 

A partir de hoy, la mítica versión de Debian 8 ha llegado al final de su ciclo de vida, por lo que esta distribución Linux dejará de recibir actualizaciones de seguridad periódicas.

Esto significa que, a partir de hoy, esta distribución está totalmente abandonada, y los distintos fallos (de estabilidad o rendimiento), así como los fallos de seguridad que se puedan descubrir para esta distro no serán solucionados. Eso sí, si por algún motivo algún usuario no puede actualizar, esta distro seguirá siendo mantenida por el equipo de Debian LTS, equipo que ha estado actualizando Debian 7 hasta el pasado 31 de mayo y que seguirá lanzando parches para los fallos más críticos hasta el 30 de junio de 2020.

De todas formas, esto no es recomendable dado que este grupo de desarrolladores no corrigen todos los fallos de seguridad (ni lanzan más actualizaciones de mantenimiento), sino que solo lanzan parches para las vulnerabilidades más críticas.

 

Cómo actualizar de Debian 8 a Debian 9 para seguir recibiendo soporte y actualizaciones de seguridad

La versión más reciente de Debian que aún recibe actualizaciones de seguridad es Debian 9.4. Aunque si queremos podemos descargar la imagen ISO de forma totalmente gratuita para realizar una instalación limpia de esta distribución Linux en nuestro sistema, si ya tenemos instalada y configurada una versión anterior y no queremos volver a pasar por esto siempre podemos actualizar nuestro Debian 8 al nuevo Debian 9.4 para, además de aprovecharnos de las mejoras que llegaron con esta distro (que no son pocas) poder seguir recibiendo actualizaciones de seguridad. Lo primero que debemos hacer es comprobar nuestro sistema para buscar y eliminar paquetes obsoletos que puedan dar problemas en la actualización. Para ello abriremos un terminal y ejecutaremos:

• aptitude search ‘~o’

Una vez eliminados los paquetes ya obsoletos, lo siguiente será actualizar la distribución. Para ello, desde la misma terminal, simplemente ejecutamos los siguientes comandos para actualizar los repositorios, las aplicaciones instaladas y, por último, los paquetes de la distro.

• apt-get update
• apt-get upgrade
• apt-get dist-upgrade

Una vez finalice el proceso ya tendremos nuestra distribución actualizada, aunque antes de dar el proceso de actualización por acabado debemos ejecutarlos siguientes comandos para asegurarnos de que tenemos todos los paquetes instalados (para que no haya conflictos) y para cambiar los repositorios de software de Jessie a Stretch:

• dpkg -C
• sed -i ‘s/jessie/stretch/g’ /etc/apt/sources.list
• apt-get update

Ahora sí podemos reiniciar ya nuestro ordenador para que, cuando vuelva a arrancar, estemos utilizando ya el nuevo Debian 9. Esta versión tendrá soporte básico hasta 2020, y un soporte extendido de dos años más, hasta 2022.

Fuente | RedesZone

Detectados contenedores maliciosos distribuidos a través de Docker Hub

544.74 Monero, lo que al cambio son unos 67.863€ a la hora de escribir este artículo. Es la cantidad que el atacante detrás de la cuenta de Docker Hub "docker123321" ha sido capaz de minar a lo largo de un año a través de imágenes maliciosas distribuidas a sistemas expuestos y, lo que es peor, usando la propia plataforma de Docker.

Durante el último año, investigadores de varias empresas (Kromtech, Fortinet y Sysdig) han estado siguiendo de cerca este caso, hasta que finalmente el pasado 10 de mayo Docker Hub cerró la cuenta maliciosa. Detrás deja un total de 17 imágenes Docker maliciosas que habían sido descargadas en más de 5 millones de ocasiones.

Linea de tiempo del ataque. Obtenida de Kromtech Security Center.

¿Cómo funciona Docker Hub?

Para explicar qué es Docker Hub, primero tenemos que ver algunos conceptos básicos de Docker. Sabemos que se basa en la ejecución de contenedores que aíslan, o al menos lo intentan, un proceso particular del sistema operativo base (ojo, no se trata de virtualización). La especificación de estos contenedores corre a cargo de las llamadas imágenes, que son plantillas donde se define qué hace exactamente un contenedor. En definitiva, un contenedor es una instancia en ejecución de una imagen. 

Aunque se puede construir una imagen desde cero, lo ideal es basarse en otra ya definida  y personalizarla. Por ejemplo, se puede crear una imagen que ejecute Apache 2 basándose en una imagen del sistema operativo Debian, instalando paquetes y configuraciones, ya sea a mano o a través de un Dockerfile. Este fichero contiene un conjunto de directivas que va a definir exactamente como queremos que se comporte el contenedor que genera esa imagen. Se pueden definir, entre otras, la imagen en la que se basa, los puertos que queremos que el contenedor abra, los paquetes que va a tener instalados o el comando que va a ejecutar. 

Una vez configurada y construida la nueva imagen, se pueden distribuir utilizando repositorios. Docker Hub es el repositorio oficial y, de hecho, está totalmente integrado en el motor Docker. Hagamos una prueba y ejecutemos 'sudo docker run -ti hello-world':

La ejecución de este contenedor nos dice exactamente qué ocurre entre bambalinas: en resumen, se busca la imagen local del contenedor que queremos ejecutar. De no existir, se busca automáticamente en Docker Hub, se descarga y se ejecuta.

¿Y quién puede publicar imágenes en Docker Hub? Cualquiera, siempre que tengamos una cuenta cuya creación es gratuita. De hecho, es el principal distribuidor de imágenes para Docker.

Medidas de seguridad en Docker Hub

Existen con ciertos "peros". Por un lado, desde Docker 1.8 se implementa el firmado de imágenes, que nos permite asegurar que la imagen que estamos descargando es precisamente la que queremos. Sin embargo, esta medida debe configurarse en el cliente y no está activada por defecto.

En segundo lugar, hasta hace poco se realizaban análisis automatizados de seguridad para las imágenes subidas a Docker Hub, aunque solo estuvo disponible para los contenedores propios. Desde hace unos meses la funcionalidad no está disponible. En la descarga, ahora mismo, no hay ningún sistema ni señal que te indique si la imagen que descargas puede tener un comportamiento malicioso o no.

Pero los usuarios de Docker no ejecutan una imagen desde Docker Hub así como así...

No deberían. Al final, es como ejecutar un proceso desconocido en nuestro equipo y, lo que es peor, con permisos de superusuario y acceso a nuestro sistema base. Por ejemplo, una de las imágenes maliciosas que se han encontrado montaba como volumen el directorio '/etc' del sistema base y añadía entradas en el fichero crontab para ganar persistencia. Pero por supuesto, un usuario sin experiencia podría encontrar una imagen que se promete interesante y ejecutarla sin una revisión de lo que hace en realidad. 

Más allá de las posibles estrategias de ingeniería social, lo que sí señalan los investigadores mencionados es que existen gran cantidad de sistemas Docker y Kubernetes (una plataforma de orquestación para Docker) que presentan fallos de configuración y están totalmente expuestos, permitiendo que reciban comandos de administración externos.

En resumen, ¿qué ha ocurrido?

Un señor con no muy buenas intenciones ha creado un repositorio en Docker Hub y ha ido publicando varias tandas de imágenes maliciosas, algunas para minar criptomonedas, a lo largo de un año.

Aunque la distribución en este caso concreto no está clara, los investigadores manejan datos de otros ataques en los que se buscaban sistemas Docker y Kubernetes expuestos a Internet (a través de escaneos automatizados y/o mediante plataformas como Shodan) y con una configuración de autenticación pobre. Una vez localizados, se les lanzaba automáticamente comandos de gestión que permitieran la descarga desde Docker Hub de las imágenes maliciosas en el sistema.

Detalle de uno de los scripts utilizados para desplegar los contenedores maliciosos. Obtenida de Kromtech Security Center.

Los contenedores se hacían pasar por sistemas como Tomcat o MySQL para pasar desapercibidos. Además de aquellos que minan Monero, otros contenedores publicados buscaban tomar el control de la máquina base a través de la apertura de shells inversas o añadiendo las claves de acceso SSH del atacante a las permitidas para el usuario root.

Con este esquema, el usuario "docker123321" ha conseguido más de 5 millones de descargas de sus contenedores, minando un total de 544.74 Monero a lo largo de un año. Después de varias notificaciones de particulares y empresas de seguridad, el usuario ha sido finalmente eliminado.

Fuente | una-al-dia