Campaña de smishing suplantando a MRW y Sending que utiliza datos de pedidos reales
Numerosos usuarios de Twitter están denunciando una campaña de smishing en la que se estaría suplantando a las empresas de logística Sending y MRW. Las primeras denuncias se producían el día 26 de diciembre, cuando clientes de marcas como Pampling, Druni o Primor informaban que Sending, el proveedor de mensajería de éstas, habría sufrido un incidente y estarían enviándose SMS en nombre de Sending solicitando datos bancarios para poder completar el envío de un pedido. Lo relevante de este caso es que los SMS recibidos hacían referencia a pedidos reales que se habían realizado, según denuncian los propios usuarios, motivo por el que se habría planteado una posible fuga de información en Sending, la cual se estaría empleando por los atacantes para dotar de credibilidad a los SMS enviados. En los SMS se incluye información personal como el nombre y el tipo de pedido, además de una URL donde se hace referencia a un dominio ilegítimo “envios-sending[.]com”, junto con un parámetro creado para que el phishing lo pueda visualizar únicamente el propio usuario. Al acceder al enlace, se puede ver ya un caso de phishing donde se solicitan datos bancarios al usuario para formalizar el envío. En las últimas horas de la tarde del lunes, comenzaban también las denuncias de casos contra MRW por el mismo fraude, lo que forzaba a la empresa a lanzar un aviso a sus usuarios alertando de la importancia de no introducir datos bancarios que se soliciten vía SMS. En este caso, al igual que ocurría con Sending, se empleaba también un dominio ilegítimo “envios-mrw[.]com”. Desde el principio de esta campaña los usuarios en redes sociales denunciaron un “hackeo” a estas empresas, siendo esta hipótesis confirmada en un comunicado emitido desde MRW el día 29 de diciembre, donde señalaban que habrían notificado una brecha de seguridad ante la Agencia Española de Protección de Datos, enunciando que se habrían visto afectados datos de carácter identificativo y de contacto de los destinatarios. Por su parte desde Sending advirtieron a sus usuarios acerca de la brecha de seguridad el mismo día 27 mediante un SMS.
Toda la información: https://www.mrw.es/comuns/noticia/sms-mrw-smishing.pdf
Vulnerabilidades en cifrados de almacenamiento de DataVault
Investigadores de seguridad han informado acerca de dos nuevas vulnerabilidades en el software DataVault, y sus sistemas derivados, empleados para el cifrado de datos en soluciones de almacenamiento de WD (propietario de SanDisk), Sony o Lexar. Uno de los fallos, se debe a la utilización de un hash criptográfico unidireccional con una clave salt predecible, lo que los convierte en vulnerables a ataques de diccionario (CVE-2021-36750). El software también emplea un hash de contraseñas con un esfuerzo computacional insuficiente, lo que permitiría a un atacante obtener las contraseñas del usuario mediante ataques de fuerza bruta, exponiendo así los datos a un acceso no autorizado (CVE-2021-36751). Ambos fallos en la función de derivación de claves se han resuelto en la versión de DataVault 7.2. por lo que se recomienda la actualización inmediata del software a dicha versión.
Más información: https://pretalx.c3voc.de/rc3-2021-r3s/talk/QMYGR3/
Avisos de exposición de contraseñas master de usuarios de LastPass
Varios usuarios estarían reportando en las últimas horas un posible compromiso de su contraseña principal (master password) del gestor de contraseñas LastPass. Las denuncias se producen tras llegarles un aviso de bloqueo de un acceso no autorizado a su cuenta de LastPass desde una ubicación desconocida. De acuerdo con la compañía, no se han encontrado indicios de la exposición de sus datos, por lo que estos bloqueos se habrían realizado según indican, al haber reutilizado los usuarios estas credenciales en otros servicios, de forma que esas podrían estar expuestas a raíz de su utilización en esos otros servicios, y serían susceptibles ser utilizadas en ataques de credential stuffing. Sin embargo, esta justificación de LastPass no encaja, según dicen algunos usuarios, con los reportes que indican habrían vuelto a recibir tras configurar nuevas contraseñas únicas. También se plantea como posibilidad, que los avisos hayan sido remitidos por error. Se desconoce, por tanto, si ha existido o no algún tipo de exposición de credenciales y el vector por el que se podrían haber expuesto. Por su parte, el investigador Bob Diachenko habría revisado si algunos de los usuarios que han denunciado haber recibido los avisos se encontraba incluido entre los afectados por malware como RedLine, descartando también esta opción. Desde LastPass han recomendado la activación del doble factor autenticación a fin de evitar accesos no autorizados. Este incidente, pone en evidencia la importancia de no reutilizar en ningún momento contraseñas entre servicios, y menos cuando se trata de la contraseña principal de un gestor de contraseñas.
Toda la información: https://www.bleepingcomputer.com/news/security/lastpass-users-warned-their-master-passwords-are-compromised/
Nueva vulnerabilidad de ejecución arbitraria de código en Log4j
Esta semana, el investigador de seguridad Yaniv Nizry volvía a sembrar el caos con una publicación en Twitter donde alertaba del descubrimiento de una nueva vulnerabilidad de ejecución remota de código en Log4j, que afectaría a la última versión 2.17.0. Algunos investigadores destacados como Kevin Beaumont invitaban a mantener la calma hasta que se conociesen más detalles y, a los pocos minutos de la publicación alertaban de la detección de supuestos exploits para este nuevo fallo que no eran sino troyanos; práctica habitual cuando se informa de fallos mediáticos como el actual. Unas horas más tarde, el investigador Marc Rogers hacía ya público el CVE asociado a esta nueva vulnerabilidad, CVE-2021-44832, e indicaba, asimismo, que para la explotación de este fallo se requiere un cambio previo de las condiciones predeterminadas, lo que complica su explotación. Esta misma idea era compartida inmediatamente por otros investigadores de renombre como Will Dorman, quien ayer, tras hacerse pública la investigación de Yaniv Nizry criticaba a Checkmarx, la firma del investigador, por crear una situación de alarma con este nuevo fallo. La explotación de este requiere que el atacante cuente con permisos de administrador en el propio sistema que quiere comprometer, puesto que, para poder explotarlo, debe poder modificar previamente el archivo de configuración de logging. Esta idea ya de por si no tiene mucho sentido, pero algunos usuarios insisten en apuntar a la figura del insider, que modifique el archivo, como posible riesgo (si bien es cierto que, de existir un insider, existen otros riesgos mayores). Dicho lo anterior, estamos por tanto ante una vulnerabilidad de ejecución arbitraria de código, no de ejecución remota como se pensaba inicialmente, y habría recibido una criticidad moderada, con un CVSSv3 de 6.6. El fallo en concreto se debe a la falta de controles adicionales en el acceso JDNI en Log4j. Apache ha lanzado ya la versión 2.17.1 para corregir el fallo. A pesar de la auto atribución del fallo por parte de Yaniv Nizry, desde Apache no han incluido su nombre en los créditos de la vulnerabilidad.
Descubre más: https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44832
The post Boletín semanal ciberseguridad 28 diciembre-3 de enero appeared first on Think Big.