Smishing campaign impersonating MRW and Sending using real order data
Numerous Twitter users are reporting a smishing campaign in which the logistics companies Sending and MRW are being impersonated. The first reports were made on 26 December, when customers of brands such as Pampling, Druni and Primor reported that Sending, their courier service provider, had suffered an incident and that SMS messages were being sent in the name of Sending requesting bank details in order to complete the delivery of an order. What is relevant in this case is that the SMSs received referred to real orders that had been placed, according to the users themselves, which is why a possible leak of information at Sending has been raised, which is being used by the attackers to give credibility to the SMSs sent. The SMSs include personal information such as the name and type of order, as well as a URL that refers to an illegitimate domain “envios-sending[.]com”, together with a parameter created so that the phishing can only be viewed by the user. When accessing the link, a phishing case can already be seen with a request for the user’s bank details in order to formalise the sending. In the last hours of yesterday afternoon, reports of cases against MRW for the same fraud also began, forcing the company to launch a notification to its users warning them of the importance of not entering bank details requested via SMS. In this case, as with Sending, an illegitimate domain “envios-mrw[.]com” was also used. Since the beginning of this campaign, users on social networks denounced a “hacking” of these companies, this hypothesis was confirmed in a statement issued by MRW on 29 December, where they indicated that they had notified a security breach to the Spanish Data Protection Agency, stating that the identity and contact details of the receivers had been affected. On the other hand, Sending warned its users about the security breach on the 27th by SMS.
All the details: : https://www.mrw.es/comuns/noticia/sms-mrw-smishing.pdf
Vulnerabilities in DataVault storage encryptions
Security researchers have reported two new vulnerabilities in DataVault software, and its derivative systems, used for data encryption in storage solutions from WD (owner of SanDisk), Sony or Lexar. One of the flaws is due to the use of a cryptographic hash with a predictable salt, which makes them vulnerable to dictionary attacks (CVE-2021-36750). The software also employs a password hash with insufficient computational effort, which would allow an attacker to obtain user passwords through brute force attacks, thus exposing the data to unauthorised access (CVE-2021-36751). Both flaws in the key derivation feature have been resolved in DataVault version 7.2, so it is recommended that the software be upgraded to that version immediately.
More info: https://pretalx.c3voc.de/rc3-2021-r3s/talk/QMYGR3/
LastPass user master password exposure reports
Several users have reported in recent hours a possible compromise of their LastPass password manager master password. The reports come after they received a lockout notice of unauthorised access to their LastPass account from an unknown location. According to the company, no evidence has been found of the exposure of their data, meaning that the blocking would have been carried out because the users had reused these credentials in other services, so that they could have been exposed as a result of their use in those other services, and could be susceptible to being used in credential stuffing attacks. However, this justification by LastPass does not fit, according to some users, with the reports that they have allegedly received again after setting up new unique passwords. It is also raised as a possibility that the warnings were sent in error. It is unknown, therefore, whether or not there has been any exposure of credentials and the vector by which they could have been exposed. For his part, researcher Bob Diachenko has checked whether some of the users who have reported having received the warnings were included among those affected by malware such as RedLine, also ruling out this option. LastPass has recommended activating two-factor authentication to prevent unauthorised access. This incident highlights the importance of never reusing passwords between services, especially when it is the main password of a password manager.
All the information: https://www.bleepingcomputer.com/news/security/lastpass-users-warned-their-master-passwords-are-compromised/
New arbitrary code execution vulnerability in Log4j
This week, security researcher Yaniv Nizry spread once again chaos with a Twitter post warning of the discovery of a new remote code execution vulnerability in Log4j, affecting the latest version 2.17.0. Some prominent researchers such as Kevin Beaumont invited people to remain calm until more details were known and, within minutes of the publication, they warned of the detection of alleged exploits for this new bug that were nothing more than trojans; a common practice when media bugs such as the current one are reported. A few hours later, the researcher Marc Rogers published the CVE associated with this new vulnerability, CVE-2021-44832, and also indicated that the exploitation of this flaw requires a prior change in the default conditions, which complicates its exploitation. This same idea was immediately shared by other renowned researchers such as Will Dorman, who yesterday, after Yaniv Nizry’s research was made public, criticised Checkmarx, the researcher’s firm, for creating a situation of alarm with this new flaw. Exploiting this flaw requires the attacker to have administrator permissions on the very system to be compromised, since, in order to exploit it, the attacker must first be able to modify the logging configuration file. This idea does not make much sense in itself, but some users insist on pointing to the figure of the insider, who modifies the file, as a possible risk (although it is true that, if there is an insider, there are other greater risks). That said, we are therefore dealing with an arbitrary code execution vulnerability, not a remote execution vulnerability as initially thought, and it would have received a moderate criticality, with a CVSSv3 of 6.6. The specific flaw is due to the lack of additional controls on JDNI access in Log4j. Apache has now released version 2.17.1 to fix the bug. Despite the self-attribution of the bug by Yaniv Nizry, who has also published an article detailing his research, Apache has not included his name in the credits for the vulnerability.
Know more: https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44832
