Xbash, un gusano multiplataforma enfocado a servidores

Este nuevo gusano para Windows y Linux escrito en Python combina ransomware, minado, botnet y capacidad de auto-propagación

Ha sido detectado un nuevo tipo de malware del que se sospecha que podría estar detrás Iron Group, un grupo cibercriminal chino ya conocido. Esta nueva amenaza destaca por contar con un amplio abanico de funciones, entre las que se encuentran ransomware (borra datos de varios tipos de bases de datos), botnet (comunicándose a servidores C2), ataques por fuerza bruta a múltiples servicios (MySQL, VNC, etc.), explotación de servicios para propagación (Hadoop, Redis y ActiveMQ) y minado. Además del alto número de opciones (que podrían ir incrementándose con el tiempo), este malware destaca por ejecutarse tanto en Windows como en Linux.

El principal riesgo que trae este malware es su capacidad como ransomware, afectando a las bases de datos MySQL, PostgreSQL y MongoDB, de las cuales borra todos sus datos y crea una nueva tabla con la información para realizar el pago. A pesar de que la cuantía por recuperar la información es relativamente pequeña (0,02 bitcoin, 125$ en estos momentos), no debería hacerse el pago bajo ningún concepto, porque el atacante no ha añadido un método de recuperación. El malware no sólo intenta acceder a las bases de datos conectándose a ellas, sino que además cuenta con métodos alternativos como utilizando PhpMyAdmin.

El atacante ya ha recibido 6000$ en Bitcoins. Fuente: Palo Alto.

Otra de las características incluidas son sus funcionalidades como botnet para analizar máquinas remotas. Para su funcionamiento, hace uso de 3 tipos de servidores C2: uno del que obtiene IPs y dominios (públicos) a analizar, otro del que obtiene contraseñas a probar, y finalmente otro al que envía los resultados. El malware cuenta con un amplio número de servicios a examinar por si estuviesen disponibles, y en caso de tener éxito (y si el servicio está implementado), intenta romper la contraseña haciendo uso de los diccionarios. Los servidores C2 se encuentran en el código, y todas las comunicaciones se realizan usando HTTP.

Para su propagación, se aprovecha de vulnerabilidades ya conocidas en Hadoop (sin CVE, de 2016), Redis (sin CVE también, 2015) y ActiveMQ (CVE-2016-3088), lo que urge aún más actualizar dichos servicios si no lo estuviesen ya. Para infectar las máquinas vulnerables, el gusano se descarga así mismo desde uno de los servidores C2 disponibles, además del Coinminer empleado por el grupo criminal. Incluso para la instalación del malware cuenta con funciones para detectar si la máquina es Windows o Linux, para así realizar la instalación de la forma correcta.

Python, el lenguaje de programación empleado, destaca por permitir un desarrollo rápido y fácil, al mismo tiempo que facilita incorporar mejoras al software. Este lenguaje de script es multiplataforma, ventaja que aprovecha para ampliar el número las plataformas a infectar. Para su instalación, utiliza PyInstaller, un contenedor que incluye todas las dependencias de Python necesarias. Además, ofusca el código para impedir que sea detectado y dificultar su análisis, aunque ya está siendo detectado por varios antivirus.

Tendremos que estar atentos al avance de este malware, que podría variar en los próximos meses para soportar nuevos métodos de ataque y propagación. Mientras tanto, se recomienda utilizar contraseñas seguras en la configuración de los servicios, mantener el software actualizado y realizar backups (sobre todo de bases de datos).

Más información:

Falso email de Deloitte usado para distribuir malware

No es la primera vez que los spammers utilizan la imagen de empresas conocidas para hacer llegar a los usuarios correos no deseados o, en el peor de los casos, malware.

 

En este caso los atacantes han suplantado la identidad de la conocida empresa Deloitte para distribuir muestras de TrickBot, una familia de troyanos bancarios que ha estado bastante activa los últimos meses.

Los correos reportados provienen de un tal “Adam Bush” Adam.Bush@deloitte-inv.com y utilizan un dominio fraudulento que incluye el nombre de la marca. El asunto del correo habla de un calendario de nóminas de la empresa y pretende despertar la curiosidad de la víctima para descargar y abrir el adjunto incluido.

Correo suplantando la identidad de Deloitte. Fuente: myonlinesecurity.co.uk

El fichero adjunto, en formato Excel, contiene una macro maliciosa que descargará el troyano. Desde las versiones de Office 2010 en adelante, el programa requiere que el usuario habilite de forma manual la ejecución de macros, por eso se mostrará en la hoja de cálculo un mensaje como el que vemos a continuación incitando al usuario a activar esta característica:

Payrollschedule.xls. Fuente: myonlinesecurity.co.uk

La macro descargará el ejecutable desde http://bcgfl[.]com/sdn.uqw o alternativamente http://ubeinc[.]com/sdn.uqw. Dos muestras del ya conocido Trickbot.

IOC de la campaña:

Payrollschedule.xls
MD5:  a628323455d1f19d1115e1626d1fabce
SHA-1:  552f531d1f8cba28da5fcc376abbc5647f438c69

URL de descarga del troyano:
http://bcgfl[.]com/sdn.uqw
72.29.67.154
http://ubeinc[.]com/sdn.uqw
72.29.90.19
MD5: cae0a5bb259d11b80e448c0c68f47f06
SHA1: 7c08e6f55738c52b7869d66a301578667b972f4b

Remitente: Adam.Bush@deloitte-inv[.]com
5.79.90.23
185.212.130.89
5.79.76.209
95.211.169.218

Dejar claro que Deloitte no ha sido en ningún momento comprometida y que el dominio fraudulento deloitte-inv.com ha sido registrado por un tercero que nada tiene que ver con la empresa.

Desde Hispasec recomendamos no abrir nunca correos con adjuntos no solicitados.

Más información:
 
fake Deloitte FW: Payroll schedule delivers Trickbot:

Newegg es la nueva víctima del grupo delictivo Magecart

Esta semana la empresa Voletix junto a RiskIQ han publicado una investigación que tiene como protagonistas al grupo de ciberdelincuentes Magecart. Esta vez la víctima ha sido la empresa minorista de ordenadores y productos electrónicos de consumo Newegg.

Magecart es un grupo de ciberdelicuentes especializado en el robo de credenciales de pago mediante el uso de “skimmers digitales”. Entre los ataques que se le han atribuido están el robo de credenciales de pago en TicketmasterBritish Airways y el caso reciente deNewegg.

Este ataque ha sido prácticamente igual que el publicado un par de semanas atrás y que afectaba a la aerolínea británica British Airways. De hecho, teniendo en cuenta la fecha de realización del ataque y no la de publicación, este ataque ha sido anterior.

En resumen, el proceso es el siguiente:

  1. Los atacantes logran acceder al servidor donde se hospeda el código que interpreta la web de la víctima, a través de cualquier vector.
  2. El atacante introduce un código Javascript fraudulento que, paralelamente al proceso de compra, envía los credenciales del usuario a un servidor controlado por los atacantes.
  3. El ataque persiste mientras el código no es detectado.

La detección puede llevarse a cabo bien por alguien externo, por la propia empresa afectada o bien por parte de las entidades bancarias. Estas últimas, debido a las denuncias de sus clientes que reclaman cargos no autorizados, alertan a la víctima.

Las entidades bancarias están más que acostumbradas a detectar patrones que identifiquen un ‘skimmer’ como foco del robo de información de credenciales bancarios. La cadena de hechos es sencilla: reciben quejas de sus usuarios por cargos no autorizados, buscan un patrón común entre ellos, y ya tienen la fuente, en este caso todos compraron previamente en Newegg.

Durante muchos años ha sido bastante común, y lo sigue siendo, la colocación de TPVsfraudulentos que roban las tarjetas que transaccionan con él. Estas nuevas técnicas solo tienen una diferencia: no existe ningún elemento hardware, en vez de ir a un TPV físico, los atacantes manipulan TPVs virtuales.

Pero volviendo al ataque, veamos que particularidades ha tenido este caso.

Lo primero que vamos a contar es el punto donde se ha introducido el código fraudulento, en este caso ha sido en el servidor secure.newegg.com.

Lo verdaderamente sorprendente esta vez ha sido como los atacantes han intentado disfrazar el ataque para permanecer el mayor tiempo en la sombra. Para ello el 13 de agosto los atacantes registraron el dominio neweggstats.com, un dominio que pretendía disfrazar las conexiones para parecer ser legítimo y al cuál enviaban la información robada. Además le compraron un certificado SSL para cifrar el tráfico y darle aún mayor sobriedad a la infraestructura fraudulenta.

Todo esto les permitió permanecer más de un mes sin levantar sospechas, con el siguiente código cargado en la url https://secure.newegg.com/GlobalShopping/CheckoutStep2.aspx

Cabe mencionar que en el caso de British Airways se usó el eslogan, con claros tintes ‘clikbaits’, de que tan solo 22 líneas de código habían sido necesarias para llevar a cabo el ataque. Este caso de Newegg es aún más ‘flagrante’ ya han sido únicamente 15 las líneas necesarias para el llevar a cabo el ataque. Así que podíamos apostar por un eslogan bastante más divertido, a mi manera de ver, que podría ser el siguiente: “Los Hackers que forman parten de Newegg han necesitado 7 lineas menos para perpetrar su ataque que en el caso de British Airways”, una tontuna enorme, ya no solo por el hecho de que el código es Javascript y hablamos de líneas, no de sentencias, sino, porque reducir este tipo de ataques a la orden que hace el envío de datos es evidenciar un completo desconocimiento sobre todo lo que conlleva ataques de este calado.

Ejecución de código remoto en Moodle Se ha publicado un error en la plataforma educativa Moodle que podría permitir la ejecución remota de código

Moodle es una popular plataforma educativa de código abierto que permite a los educadores crear y gestionar tanto usuarios como cursos de modalidad e-learning. Además proporciona herramientas para la comunicación entre formadores y alumnos.

Existe un error al importar un cuestionario de tipo ‘arrastrar y soltar en el texto’ (ddwtos) en formato XML, debido a una falta de comprobación en una función ‘unserialize’. Esto podría causar una inyección de objetos PHP y conducir a una ejecución remota de código arbitrario.

Es necesario disponer de permisos para crear un cuestionario o importar preguntas para poder aprovechar esta vulnerabilidad. Aunque estos permisos los tienen los profesores, cabe destacar que es posible asignar el rol de ‘profesor’ un usuario ‘estudiante’ para un determinado curso, con lo cual estaría en posición de explotar este error.

Además, una plataforma Moodle también podría verse afectada de manera no intencionada si se importan cuestionarios o preguntas desde fuentes que no son de confianza.

Se propone la siguiente prueba de concepto que ejecuta el comando ‘whoami’ como demostración de la vulnerabilidad.

Prueba de concepto

Esta vulnerabilidad, identificada como CVE-2018-14630, ha sido descubierta por Johannes Moritz. Ha sido catalogada como seria por la propia plataforma y afecta a todas las versiones anteriores a las siguientes: 3.1.14, 3.3.8, 3.4.5, y 3.5.2, en las cuales se ha corregido.

Más información:
 
MSA-18-0017: Moodle XML import of ddwtos could lead to intentional remote code execution:

Error de la API de Twitter expone mensajes privados de los usuarios

Un error en la API de Twitter expuso los mensajes directos de algunos usuarios a desarrolladores de aplicaciones de terceros no autorizados.

El error que ha dado pie a esta desprivatización de mensajes (si se puede llamar así) ha estado presente desde mayo de 2017 hasta el 10 de septiembre que se descubrió y parcheó.

“Si interactuaba con una cuenta o empresa en Twitter que dependía de un desarrollador que utilizaba la AAAPI para proporcionar sus servicios, es posible que el error haya provocado que algunas de estas interaccione se envíen involuntariamente a otro desarrollador registrado”, explica Twitter.

Como funciona el error:

La compañía no ha querido dar muchos datos al respecto, pero si ha aclarado que el error se encontraba en el funcionamiento de la AAAPI propia de la compañía.

En algunos casos, el error puede haber incluido el envío de ciertos mensajes directos o tweets protegidos a desarrolladores no autorizados”, advierten publicamente.

Cabe señalar que el error solo involucra los DM de los usuarios y las interacciones con las empresas que utilizan Twitter para servicios como atención al cliente.

¿Cuantos usuarios están afectados?

A pesar de que no han descubierto ninguna evidencia de que un desarrollador equivocado haya recibido mensajes privados o tweets protegidos, la compañía no puede confirmar que no haya sucedido. Por lo que, potencialmente pueden estar afectadas más de 3 millones de personas (menos del 1% de los usuarios de la red social).

¿Qué puedes hacer si eres uno de los afectados con los que Twitter ha contactado?

 
Esperar. Twitter asegura que ya han contactado con todos los desarrolladores que podrían haber recibidos datos “no deseados” para que, de ser así, los eliminen con la mayor brevedad. 


Esto no es más que una demostración más de que la seguridad no es una ciencia exacta y que nunca podemos asegurar estar 100% libre de peligro en Internet, por lo que debemos minimizar el riesgo al mínimo posible.


Más información:
 
Tweet de la compañía al respecto:

Explotando el método PUT para vulnerar servidores web

Explotar el método PUT es una tarea sencilla que puede ahorrarnos mucho trabajo en un pentesting

Todos conocemos los mítidos métodos GET y POST. Pero realmente hay muchos más métodos HTTP que pasan desapercibidos para los usuarios, algunos de los cuáles pueden ser muy peligrosos tener habilitados en nuestras webs.

Métodos HTTP:

  • GET:
    El método GET solicita una representación de un recurso específico.
  • POST:
    El método POST se utiliza para enviar una entidad a un recurso en específico, causando a menudo cambios en el estado.
  • HEAD:
    El método HEAD pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo de la respuesta.
  • PUT:
    El método PUT reemplaza todas las representaciones actuales del recurso solicitado con la carga útil de la petición (sube un archivo).
  • DELETE:
    El método DELETE borra un recurso en específico.
  • CONNECT:
    El método CONNECT establece un túnel hacia el servidor identificado por el recurso.
  • OPTIONS:
    El método OPTIONS es utilizado para describir las opciones de comunicación (métodos HTTP) permitidos en el recurso de destino.
  • TRACE:
    El método TRACE realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta al recurso de destino (utilizado para ataques XST).
  • PATCH:
    El método PATCH es utilizado para aplicar modificaciones parciales a un recurso.

Hay numerosos métodos más, pero creo que con estos por hoy tenemos suficiente. Se puede comprobar que hay mundo más allá de los métodos GET y POST que solemos utilizar. Hoy, de entre todos ellos vamos a centrarnos en el método PUT, el cuál se puede considerar el más peligroso de todos.

¿Cómo sabemos que una web tiene habilitado el método PUT?

Hay numerosas formas de conocer este dato y cada uno tiene sus preferencias. En este caso os voy a explicar los dos métodos que yo suelo utilizar.

  • Mediante el uso del método OPTIONS:

Vemos como al hacer una petición con este método, nos devuelve los métodos disponibles en la web.

  • Mediante el uso de nmap:

Usando uno de los script que vienen predeterminados con esta herramienta también podríamos ver los métodos admitidos por el servidor.

➜ ~ nmap -p80 –script http-methods 192.168.1.80
Starting Nmap 7.70 ( https://nmap.org ) at 2018-09-27 10:15 CEST
Nmap scan report for 192.168.1.80
Host is up (0.00041s latency).

PORT STATE SERVICE
80/tcp open http
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS DELETE TRACK PROPFIND PROPPATCH COPY MOVE LOCK UNLOCK

Es importante saber que estas opciones no son 100% infalibles ya que a veces no te dicen algún método que si está permitido, y otras te dan falsos positivos.

¿Cómo explotamos el método PUT?

Como he descrito antes, el método PUT sirve para subir una carga útil al servidor, por lo que para explotarlo únicamente necesitamos hacer una petición con este método y la carga que queremos subir.
En este caso subimos una página HTML con un ‘Hola’. Vemos que nos da un 200 y comprobamos si de verdad ha sido creada.

Ya tenemos un claro ejemplo de como explotar este método.

Automatizando el proceso de explotación:

Como toda tarea informática en este mundo, se puede automatizar. Para este tipo de ataque he creado un pequeño script que realiza las siguientes acciones:

  • Crea una shell reversa.
  • Comprueba que está activo el método PUT y sube la shell al servidor en la ruta que le especifiquemos.
  • Nos pone un listener de Metasploit a la escucha para que cuando visitemos la URL de la shell consigamos una consola de Meterpreter.

Todo el que quiera usar este script, lo tiene disponible aquí.

Happy hacking ;).

Más información:
 
Repositorio del script en Github:

Salto de autenticación con permisos administrador en Western Digital My Cloud

La vulnerabilidad, que en estos momentos no cuenta con una solución, permite ejecutar acciones como administrador simplemente estableciendo una cookie

Tanto los investigadores de exploitee.rs como de Securify han encontrado un fallo (CVE-2018-17153) en Western Digital My Cloud que permitiría realizar acciones como administrador en uno de los dispositivos afectados. Se desconocen los modelos exactos vulnerables, pero seguramente sea un gran número de ellos al compartir código. Los investigadores realizaron sus pruebas en el modelo WDBCTL0020HWT ejecutando la versión 2.30.172.

La vulnerabilidad es muy fácil de explotar, y no tiene más requerimientos que tener conexión con el dispositivo. Para su explotación, sólo se requieren 2 pasos: primero, realizar una petición POST form a ‘/cgi-bin/network_mgr.cgi’incluyendo cmd=cgi_get_ipv6&flag=1‘, creando así la sesión. Segundo, realizar una petición con un comando que requiera autenticación (por ejemplo, cgi_get_ssh_pw_status) agregando la cookie username=admin.

Los discos duros Western Digital My Cloud son empleados en el mercado doméstico y  PYMES para almacenar backups e información personal, por lo que son objetivo de ransomware (además de botnets) al estar conectados de forma continua a la red. La empresa fue informada en abril de 2017, pero ésta ha ignorado el reporte, por lo que se ha publicado ahora en septiembre de 2018.

En caso de contar con un dispositivo vulnerable, la primera medida a adoptar es impedir el acceso al dispositivo desde Internet (lo cual debería realizarse en cualquier caso), aunque la solución ideal es desconectar el disco duro de la red, y acceder únicamente a través de cable USB, al menos hasta que se solucione la vulnerabilidad.

Más información: