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.

Cualquiera con el enlace adecuado podría acceder a la información, que incluía las contraseñas de uno de los servidores de ficheros de la organización, las credenciales de un sistemas de video conferencia y de un servidor de desarrollo de una de las oficinas de Coordinación de Asuntos Humanitarios.

El investigador de seguridad Kushagra Pathak que ha descubierto el «leak» ha notificado sus hallazgos a la organización, que a lo largo de este mes ha ido eliminando todo el material.

Pathak descubrió muchos de estos recursos haciendo simples búsquedas en Google, que dieron como resultado tableros de Trello públicos que contenían a su vez otros enlaces a documentos de Google Docs y páginas de Jira.

A pesar de que los tableros de Trello y los documentos de Google son privados por defecto, Pathak ha sugerido a Trello añadir medidas adicionales para evitar que los usuarios publiquen sus tableros por error. A lo que el CEO de Trello ha respondido:

«Nos esforzamos por asegurarnos de que los tableros públicos se crean de manera intencionada, haciendo necesaria una confirmación previa del usuario y mostrando en la parte superior de los tableros la visibilidad del mismo».

Los descubrimientos de Pathak ponen de manifiesto la falta de concienciación en materia de seguridad informática y los riesgos que una fuga de información de estas características supondría para grandes empresas y organizaciones.

https://moodle.org/mod/forum/discuss.php?d=376023

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 Ticketmaster, British Airways y el caso reciente de Newegg.

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.

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.

Se han descubierto varias vulnerabilidades en el sistema de bloqueo que utiliza la plataforma de alquiler de bicicletas oBike. Un atacante remoto podría eludir el mecanismo de bloqueo mediante ataques de repetición para reproducir textos cifrados en función de valores predecibles.

oBike es una plataforma de alquiler de bicicletas sin estaciones (se pueden recoger y entregar en cualquier ubicación donde esté permitido aparcar bicicletas o vehículos) originaria de Singapur, opera en más de 40 ciudades de Europa, Asia y Oceanía.

Desde la aplicación para smartphones, el cliente reserva una bicicleta que se encuentre ubicada cerca de su zona y mediante el escaneo de un código QR puede desbloquear y comenzar a utilizar la bicicleta gracias a un dispositivo IoT integrado en ella que actúa como sistema de bloqueo. En el momento en que la bicicleta es desbloqueada comienza el periodo de alquiler por el cual se facturará en tramos de 30 minutos.

Concretamente el protocolo de comunicación utilizado por oBike es el siguiente:

Protocolo de comunicación de la plataforma oBike

La app envía un mensaje de saludo [1] con las coordenadas GPS para desbloquear la bicicleta a través de Bluetooth (BLE o ‘Bluetooth Low Energy’) y recibe una cadena de 32 bits utilizada como desafío (‘keySource’) [2]. Esta cadena se envía a los servidores de oBike [3] donde se procesa y se devuelve a la app [4] un índice de clave ‘encKey’ y un texto cifrado de 128 bits en ‘keys’. Nuevamente a través de BLE, la app envía a la bicicleta el texto cifrado truncado a 96 bits y el índice de clave ‘encKey’ [5] y la bicicleta es desbloqueada emitiéndose una respuesta de confirmación [6] con los valores ‘macKey’ e ‘index’. Como último paso, la aplicación envía a los servidores de oBike estos dos valores en el mensaje ‘lockMessage’ [7] con el cual el alquiler de la bici queda registrado y se inicia el periodo de facturación.

Previamente, al analizar este protocolo, se descubrieron algunas vulnerabilidades que se exponen en el proyecto ‘Exploration of Weakness in Bike Sharing System’realizado por estudiantes de la ‘School of Computing (National University of Singapure)’en 2017-2018. Estas podrían permitir falsear la ubicación de las bicicletas, realizar una denegación de servicio al hacer que el servidor establezca que la bicicleta está defectuosa por lo que dejaría de aceptar intentos de desbloqueo, e incluso omitir la confirmación en el paso 7, con lo cual la bicicleta quedaría desbloqueada pero el alquiler no sería registrado y por tanto el cobro tampoco sería efectuado.

Un análisis más reciente realizado por Antoine Neuenschwander ha determinado que:

• El campo ‘keySource’ (usado en el paso [2]) no es un valor aleatorio generados por el dispositivo IoT de bloqueo sino que representa la cantidad de milisegundos desde que se encendió el chip (lo cual corresponde a una ventana temporal de algo menos de 50 días: 2^32 milisegundos).
• El texto cifrado de 128 bits ‘keys’, resultante de una operación criptográfica desconocida basada en los valores ‘keySource’ y ‘encKey’, probablemente utilice un cifrado AES-128.
• ‘encKey’ selecciona la clave de encriptación de un conjunto de 64 índices distintos determinados por el servidor.

También se ha observado que si se fijan los valores ‘keySource’ y ‘encKey’, el valor resultante de ‘keys’ es siempre igual. Esto permitiría realizar ataques de repetición para desbloquear la bicicleta, enumerando todos los valores posibles de ‘keySource’ y capturando los valores correspondientes ‘keys’ y ‘encKey’ siendo posible reproducir estos valores posteriormente y de forma offline, sin necesidad de conectar con el servidor. Además es posible limitar el número de valores a enumerar gracias a un comando BLE que provoca un reinicio del chip, con lo que el ataque se simplifica en gran medida.

Esta vulnerabilidad tiene asignado el identificador CVE-2018-16242.

Más información:

 

obike:

https://www.o.bike

CVE-2018-16242:

https://nvd.nist.gov/vuln/detail/CVE-2018-16242

Exploration of Weaknesses in Bike Sharing System:

http://isteps.comp.nus.edu.sg/event/11th-steps/module/CS3235/project/3

Reverse engineering of the oBike protocol communication (BLE and HTTP):

https://github.com/antoinet/obike

Revelación de información, elevación de privilegios, falsificación de contenido… Éstas son algunos de los impactos asociados a las vulnerabilidades que se abordan en el último boletín de Apple para su sistema operativo iOS en su versión 12. Además de usarse en el archiconocido iPhone, también está presente en la mayoría de los dispositivos móviles de la marca como el iPad o el iPod touch. Esta vez, todas las vulnerabilidades reportadas tienen un identificador CVE asociado. A continuación, repasamos las vulnerabilidades contenidas en el boletín:

• CVE-2018-4322
  • Módulo: Accounts
  • Impacto: Una aplicación puede obtener un identificador persistente de una cuenta
  • Solución: Mejora del sistema de permisos

• CVE-2018-5383
  • Módulo: Bluetooth
  • Impacto: Un atacante en una posición privilegiada de la red puede interceptar tráfico
  • Solución: Mejora de validación de entradas

• CVE-2018-4330
  • Módulo: Core Bluetooth
  • Impacto: Una aplicación puede ejecutar código arbitrario con privilegios del sistema
  • Solución: Mejora del manejo de memoria para evitar su corrupción

• CVE-2018-4356
  • Módulo: CoreMedia
  • Impacto: Una aplicación puede obtener información sobre lo que ve la cámara antes de tener concedido el acceso a ella
  • Solución: Mejora de validación de permisos

• CVE-2018-4305
  • Módulo: iTunes Store
  • Impacto: Un atacante en una posición privilegiada de la red puede falsear diálogos que piden contraseñas
  • Solución: Mejora de validación de entradas

• CVE-2018-4363
  • Módulo: Kernel
  • Impacto: Una aplicación puede leer memoria restringida
  • Solución: Mejora del validación de entradas en el kernel

• CVE-2018-4313
  • Módulo: Messages
  • Impacto: Un usuario local puede descubrir mensajes borrados de un usuario
  • Solución: Mejora en el borrado de mensajes

Todas las vulnerabilidades han sido corregidas por Apple en la última versión disponible de iOS 12.
Más información:

Sabri Haddouche es el nombre del investigador que ha descubierto este fallo. La prueba de concepto liberada fue colgada en Twitter y en su Github. Más allá de un simple bloqueo, la página web, si se visita, provoca un pánico en el kernel del dispositivo y un reinicio completo del sistema. 

Explicación del fallo:

El exploit aprovecha una debilidad en el motor de renderizado de Apple Webkit, que es utilizado por todas las aplicaciones y navegadores de la conocia marca. Dado que Webkit no cargaba correctamente varios elementos como etiquetas <div> dentro de una propiedad del filtro CSS, el investigador creó una web que utiliza todos los recursos del dispositivo, provocando el apagado y reinicio del mismo. 

Prueba de concepto:

Todos los navegadores que corren sobre iOS son vulnerables a este ataque. Por otro lado, los usuarios de Windows y Linux no se ven afectados por esta vulnerabilidad.

De momento no hay parche disponible contra este fallo, pero se presupone que Apple está investigando el problema.

La ausencia de control de acceso en uno de los procesos que se comunican con el driver del kernel de Webroot SecureAnywhere, permitirían la desreferencia de un puntero controlado por un usuario (sin privilegios) para leer y escribir en una dirección arbitraria.

La vulnerabilidad ha sido corregida en la versión 9.0.8.34 de SecureAnywhere.

Extraída de https://thehackernews.com

El ataque ‘Cold Boot’ o de ‘Inicio en frío’ es un ataque que se descubrió hace una década y que permitiría a un atacante con acceso físico a una máquina robar claves de cifrado entre otra información sensible. Este ataque consistía en reiniciar el ordenador sin en proceso adecuado de apagado, lo que podría permitir recuperar los datos existentes en la memoria RAM antes de que sean eliminados.

Pasos de realización del ataque, extraída de https://blog.f-secure.com

El problema fue subsanado aplicando un proceso de sobreescritura a los datos existentes en la memoria, impidiendo que la información pudiera ser robada. Ahora los investigadores de seguridad aseguran haber descubierto una manera de deshabilitar este proceso, lo que les permitiría realizar un ataque ‘Cood Boot’ al sistema.

Los investigadores también alertan de que este error existe en la mayoría de los ordenadores de hoy en día y aunque los ataque son en frío, no son fáciles de llevar a cabo. Los atacantes deben disponer de tiempo y formas consistentes y confiables para comprometer los equipos objetivos, ya que hay que tener acceso físico a ordenador en cuestión y herramientas adecuadas.

“It’s not exactly easy to do, but it’s not a hard enough issue to find and exploit for us to ignore the probability that some attackers have already figured this out,” says Olle. “It’s not exactly the kind of thing that attackers looking for easy targets will use. But it is the kind of thing that attackers looking for bigger phish, like a bank or large enterprise, will know how to use.”

Los investigadores aseguran que el error no tiene fácil solución y que cada fabricante tendrá que lidiar con el problema. Aún así, Microsoft y Apple están trabajando en una solución conjunta.

Aunque ahora mismo no existe ningún parche oficial, los de Redmon han actualizado sus contramedidas con BitLocker. Por su parte, los de la manzana, han actualizado sus recomendaciones de seguridad, en especial para aquellas personas cuyo ordenador no posea un chip T2, el cual supuestamente ya está protegido frente a este ataque.

El error ha sido presentado en la conferencia SEC-T en Suecia, y el próximo día 27, volverán a hacer una presentación en la conferencia de Microsoft BlueHat v18.

Actualmente los errores han sido reportados a Microsoft y a Apple con los que colaboran para una correcta solución.

Durante más de una década, el uso de PSK (clave pre-compartida, comúnmente conocido como ‘four-way handshake’) se ha considerado seguro, hasta que en 2016 un grupo de investigadores belgas descubrieron lo que se denominaría KRACK, dejando de manifiesto la necesidad de buscar una alternativa: SAE (Simultaneous Authentication of Equals).

Este nuevo protocolo empleado por WPA3 (que en realidad data de 2008), se trata de una variación de dragonfly handshake, contando entre sus novedades resistencia a ataques como el de KRACK, pero además hace inútil los ataques por diccionario a los paquetes interceptados. Por si fuese poco, además cuenta con ‘forward secrecy’. Esto significa, que aunque se obtenga la clave, un atacante no podrá descifrar los mensajes anteriormente cifrados con dicha clave, porque ésta cambia con cada comunicación.

SAE a diferencia de PSK, tal y como indica su nombre (Simultaneous Authentication of Equals) trata a cada cada parte como iguales, y cualquiera de ellas puede establecer la comunicación. Este nuevo método se contrapone a la forma de trabajar de PSK, en que router y cliente se encontraban diferenciados, y era posible forzar la desconexión entre ambos para analizar los ‘handshake’ (tal y como hace KRACK).

Además de SAE, WPA3 en su modalidad WPA3-Enterprise contará con cifrado de 192-bits, al contrario que WPA3-Personal, que utilizará 128-bits. Esta seguridad adicional puede ser excesiva para el mercado doméstico, pero su uso puede ser requerido por instituciones y gobiernos.

WPA3 no es sólo más seguro, sino también más fácil de usar. Muestra de ello es Easy Connect, un nuevo protocolo que ha sido creado para facilitar compartir (y seguro) el acceso a una red. Esta nueva modalidad hace uso de códigos QR únicos, que deben ser escaneados por los dispositivos. Para aquellos dispositivos sin posibilidad de escanear el código QR, también será posible utilizar un código legible por un ser humano, e incluso compartirlo mediante sonido. Este tipo de medidas evitan compartir la contraseña (lo cual es más inseguro) y reduce los errores comunes al almacenar la clave para compartirla (a.k.a apuntarlo en un post-it). Sólo esperemos que estas nuevas facilidades, no se conviertan en un agujero de seguridad, como ya ocurrió con WPS.

Relacionado con lo anterior, el nuevo protocolo Enhanced Open protegerá a los usuarios que se conecten a redes abiertas, como aeropuertos o cafés, de ver sus datos comprometidos por el resto de usuarios de la red. Éste es un problema grave existente hasta ahora del que muchos usuarios no son conscientes, siendo la única solución utilizar una VPN (algo, que la mayoría de personas no utilizarán). Aunque el uso de una VPN en una red desconocida seguirá siendo aconsejable (porque no sabemos quien controla la red), este nuevo protocolo protegerá en gran medida a los usuarios que no usen una VPN.

ProtonVPN es un servicio ofrecido por la compañía Proton Technologies, esta compañía es famosa por un servicio de email llamado «ProtonMail» uno de los servicios de correos más seguros del momento.

Hace poco la empresa apostó por hacer un servicio VPN usando la misma visión que con el servicio de email. Y han empezado a aparecer ya algunas vulnerabilidades del lado del cliente.

El cliente de ProtonVPN se divide en dos partes, por un lado está la ‘GUI (Interfaz gráfica)’que se ejecuta con privilegios estándar y el propio servicio que corre con los privilegios del sistema.

Esta vulnerabilidad fue reportada por el equipo en julio y el parche ha llegado en una actualización del 3 de septiembre. Se recomienda actualizar los  clientes a la versión actual.