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

Microsoft bloquea Flash en Office 365 para que sea más seguro

Hemos visto progresivamente cómo ha ido desapareciendo Flash de diferentes plataformas con el paso del tiempo. Hoy nos hacemos eco de la reciente noticia de Microsoft que acaba de anunciar la intención de bloquear el contenido Flash en Office 365. Eso sí, no va a ser de forma inmediata. Todavía quedan unos meses para que llegue ya que está previsto para enero de 2019. Tampoco afectará a todos los contenidos.

Office 365 bloqueará Flash

El bloqueo se aplicará a clientes de Office 365. No afectará, por tanto, a aquellos usuarios que cuenten con Office 2010, Office 2013 o la versión Office 2016. Así lo ha confirmado la compañía.

Esto significa que Office 365 evitará que el contenido de Flash, Shockwave o Silverlight se reproduzca en documentos de Office. Se trata de un bloqueo completo. Sin embargo únicamente se bloquean los contenidos de Flash, Shockwave y Silverlight integrados con la función “Insertar objeto”, pero no los incorporados a través de “Insertar vídeo en línea”.

Estas dos funciones, “Insertar objeto” e “Insertar vídeo en línea”, se diferencian en que el primero utiliza la tecnología OLE (enlace e incrustación de objetos, en sus siglas en inglés) y el segundo integra contenido utilizando para ello una función de Internet Explorer.

Las razones del bloqueo de Flash en Office 365 son variadas. Desde Microsoft explican que los ciberdelincuentes han abusado continuamente de este mecanismo para introducir malware. Además, aseguran que los clientes de Office 365 realmente utilizan muy poco esta función.

Desde la compañía también han informado de que esta decisión estaba tomada después de que Adobe anunciara el final de Flash para el año 2020. Microsoft dejó de soportar Silverlight en 2016, y la fecha final de soporte para clientes empresariales está programada para el 2021.

Eso sí, para aquellas compañías que necesiten incrustar o ver contenido en Flash o que esté basado en Silverlight en Office 365, podrán acceder a una página de soporte donde encontrarán información para poder reactivar estas funciones. La idea es que no afecte a los usuarios.

El uso de Flash ha bajado mucho

Como sabemos, el uso de Flash ha disminuido notablemente en los últimos años. Si tiramos de datos concretos, Google Chrome afirmó recientemente que en 2014 el número de usuarios que cargaban al menos una página en Flash cada día era del 80%. En la actualidad, en 2018, esta cifra se ha reducido enormemente hasta representar únicamente un 8%. La tendencia es que siga bajando.

En definitiva, Microsoft va a eliminar Flash en Office 365 entre otras razones para aumentar la seguridad de los usuarios. Una manera añadida de evitar posibles ataques de malware dirigidos a sus clientes. En artículos anteriores hemos visto casos de vulnerabilidades de Flash que afectaban a los usuarios.

Una de las mejores formas de evitar ser víctimas de este tipo de ataques es tener actualizados nuestros sistemas y programas. Con los parches de seguridad pueden corregirse algunas vulnerabilidades y evitar ser explotadas por parte de los ciberdelincuentes.

Fuente | RedesZone