Activity dubbed ‘Raspberry Robin’ uses Microsoft Standard Installer and other legitimate processes to communicate with threat actors and execute nefarious commands.

Activity dubbed ‘Raspberry Robin’ uses Microsoft Standard Installer and other legitimate processes to communicate with threat actors and execute nefarious commands.

Credit: Red Canary

Wormable malware dubbed Raspberry Robin has been active since last September and  is wriggling its way through USB drives onto Windows machines to use Microsoft Standard Installer and other legitimate processes to install malicious files, researchers have found.

Researchers at Red Canary Intelligence first began tracking the malicious activity in the fall when it began as a handful of detections with similar characteristics first observed in multiple customers’ environments by Jason Killam from Red Canary’s Detection Engineering team.

Once the worm spreads via a USB drive to someone’s machine, the activity relies on msiexec.exe to call out to its infrastructure–which is often comprised of QNAP devices–using HTTP requests that contain a victim’s user and device names, Red Canary’s Lauren Podber and Stef Rand wrote in a blog post published Thursday.

Researchers also observed Raspberry Robin use TOR exit nodes as additional command and control (C&C) infrastructure, they wrote. Eventually the worm installs malicious dynamic link library (DLL) files found on the infected USB.

While researchers first noticed Raspberry Robin as early as September 2021, most of the activity observed by Red Canary occurred during January of this year, researchers said.

****Unanswered Questions****

Though researchers observed various processes and executions by the malicious activity, they acknowledged that these observations have left a number of unanswered questions.

The team has not yet figured out how or where Raspberry Robin infects external drives to perpetuate its activity, though it’s likely this infection occurs offline or “otherwise outside of our visibility,” researchers said.

They also don’t know why Raspberry Robin installs a malicious DLL, although they believe it may be to  attempt to establish persistence on an infected system–though there is not enough evidence to make this conclusive, researchers acknowledged.

However, the biggest question mark surrounding the worm is the objective of the threat actors behind it, researchers said.

“Absent additional information on later-stage activity, it’s difficult to make inferences on the goal or goals of these campaigns,” they acknowledged.

****Initial Access and Execution****

Infected removable drives—typically USB devices—introduce the Raspberry Robin worm as a shortcut LNK file masquerading as a legitimate folder on the infected USB device, researchers said. LNK files are Windows shortcuts that point to and are used to open another file, folder, or application.

Soon after the infected drive is connected to the system, the worm updates the UserAssist registry entry and records execution of a ROT13-ciphered value referencing a LNK file when deciphered. For example, researchers observed the value q:\\erpbirel.yax being deciphered to d:\\recovery.lnk, they wrote.

Execution commences when Raspberry Robin uses cmd.exe to read and execute a file stored on the infected external drive, researchers said.

“The command is consistent across Raspberry Robin detections we have seen so far, making it reliable early evidence of potential \[worm\] activity,” they noted.

In the next phase of execution, cmd.exe typically launches explorer.exe and msiexec.exe. The former’s command line can be a mixed-case reference to an external device–a person’s name, like LAUREN V; or the name of the LNK file, researchers said.

The worm “also extensively uses mixed-case letters in its commands,” most likely to avoid detection, researchers added.

****Secondary Execution****

Raspberry Robin uses the second executable launched, msiexec.exe , to attempt external network communication to a malicious domain for command and control purposes, researchers revealed.

In several examples of the activity that researchers have observed, the worm has used msiexec.exe to install a malicious DLL file although, as mentioned before, they still aren’t certain what the purpose of the DLL is.

The worm also uses msiexec.exe to launch a legitimate Windows utility, fodhelper.exe, which in turn spawns rundll32.exe to execute a malicious command, they observed.

“Processes launched by fodhelper.exe run with elevated administrative privileges without requiring a User Account Control prompt,” researchers noted. As this is unusual behavior for the utility, this activity can be used to detect the presence of Raspberry Robin on an infected machine, they said.

The rundll32.exe command then starts another legitimate Windows utility– odbcconf.exe–and passes in additional commands to execute and configure the recently-installed malicious DLL file, researchers said.

USB-based Wormable Malware Targets Windows Installer

uClibc-ng through 1.0.40 and uClibc through 0.9.33.2 use predictable DNS transaction IDs that may lead to DNS cache poisoning. This is related to a reset of a value to 0x2.

Nozomi Networks Labs discovered a vulnerability (tracked under CVE-2022-30295, ICS-VU-638779, VU#473698) affecting the Domain Name System (DNS) implementation of all versions of uClibc and uClibc-ng, a popular C standard library in IoT products. The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.

According to their respective official websites, uClibc is known to be/have been used by major vendors such as Linksys, Netgear, and Axis (only until 2010, newer Axis products include other libraries), as well as Linux distributions such as Embedded Gentoo. uClibc-ng is a fork specifically designed for OpenWRT, a common OS for routers possibly deployed throughout various critical infrastructure sectors.

Because the library maintainer was unable to develop a fix, this vulnerability remains unpatched. For this reason, we are not disclosing the details of the devices on which we were able to reproduce the vulnerability.

In this blog, we start with a background of C Standard Libraries used in IoT devices, present a technical analysis of the issue and detail its exploitability, and then provide a comprehensive timeline of the disclosure process.

A new unpatched vulnerability discovered by Nozomi Networks Labs affects the DNS implementation of all versions of uClibc and uClibc-ng.

**Background: C Standard Libraries and uClibc**

In computing, a library is a collection of resources (functions, configuration data, specifications, etc.) that is shared among software. The purpose of libraries is to provide standard primitives that software can use to perform common operations (such as to access a file on a disk or perform a network operation), without the necessity of reimplementing them all the time.

A C standard library is no exception, in the sense that it is a library for the C programming language itself. A real-world example can be found in the well-known C “Hello, World!” program. When we type the pre-processor command “#include <stdio.h>” and invoke an output function (for instance, “printf”) to print “Hello, World!”, we are actually executing the code of the chosen output function provided by the selected C standard library for the implementation of the header file “stdio.h”.

Of note, uClibc is one of the possible C standard libraries available, and specifically focuses on embedded systems. Other famous C standard libraries are glibc (GNU C library), the musl libc, or the Microsoft C run-time library (CRT).

It’s important to note that a vulnerability affecting a C standard library can be a bit complex. Not only would there be hundreds or thousands of calls to the vulnerable function in multiple points of a single program, but the vulnerability would affect an indefinite number of other programs from multiple vendors configured to use that library.

**Domain Name System (DNS)**

As we know, in modern computer networks the DNS is a hierarchical database that serves the primary, and crucial, purpose of translating a domain name into its related IP address, allowing users to access resources by more easily by memorizing human-friendly names instead of complex sequences of numbers.

Under the hood, DNS requests are mostly transmitted through UDP, which is a connectionless protocol. Thus, in order to distinguish the responses of different DNS requests, besides the usual 5-tuple {source IP, source port, destination IP, destination port, protocol} and of course the query, each DNS request includes a parameter called “transaction ID”. This is a unique number per request that is generated by the client, added in each request sent, and that must be included in a DNS response to be accepted by the client as the valid one for a corresponding request. If this condition is false, the response is discarded; if true (and other checks are satisfied as well), the response is accepted and the program that asked for a translation of a certain domain name can initiate the connection to the IP address provided.

**Figure 1.** Example DNS request. The 5-tuple, txID, and query are highlighted in the red.

Similar to other C standard libraries, uClibc provides an extensive DNS client interface that allows programs to readily perform lookups and other DNS-related requests.

**Poisoning Attacks to DNS**

Because of its relevance, DNS can be a valuable target for attackers. In a DNS poisoning attack, an attacker is able to deceive a DNS client into accepting a forged response, thus inducing a certain program into performing network communications with an arbitrarily defined endpoint, and not the legitimate one. A DNS poisoning attack enables a subsequent Man-in-the-Middle attacks  because the attacker, by poisoning DNS records, is capable of rerouting network communications to a server under their control. The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them. The main issue here is how DNS poisoning attacks can force an authenticated response.

To have a DNS response accepted for a certain DNS request, the aforementioned 5-tuple, the query, and the transaction ID must be correctly set. Given that 1. the protocol is DNS, 2. the destination port is 53/udp, 3. the query is the target that an attacker wants to compromise, 4. the source IP address is the target machine, and 5. the destination IP address is public information (it is the IP address of the DNS server in use in a certain network), the only unknowns remain the source port and the transaction ID. It is vital that these two parameters are as unpredictable as possible, because if they are not, a poisoning attack could be possible. 

**Vulnerability Details**

While we were reviewing the trace of DNS requests performed by an IoT device under test in our lab, we noticed the pattern of DNS requests performed from the output of Wireshark. If you look at the below screenshot (Figure 2) you can see that the transaction ID is first incremental, then resets to the value 0x2, then is incremental again.

**Figure 2.** Trace of DNS requests performed by an IoT device under test

While debugging the related executable, trying to understand the root cause, we eventually noticed that the code responsible for performing the DNS requests was not part of the instructions of the executable itself, but was part of the C standard library in use, namely uClibc 0.9.33.2 (“libuClibc-0.9.33.2.so”).

A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.

**Figure 3.** DNS lookup function of uClibc.

In reference to line #1240, the function declares a static variable “last_id”. This variable contains the value of the transaction ID used in the last DNS request, and is initialized with the value 1 at the first invocation of “__dns_lookup”.

Additionally, at line #1260, the function declares a variable “local_id”. This variable contains the value of the transaction ID that will be used in the upcoming DNS request, and is left uninitialized.

Afterwards, the following lines of code are executed.

**Figure 4.** DNS lookup function of uClibc (2).

In reference to line #1309, at the first DNS request, the “local_id” variable is initialized with the value of the transaction ID of the last DNS request (“last_id”). Line #1320 is the actual core of the vulnerability: “local_id” is updated by incrementing its old value by 1. Given that the value is initialized to 1 at the first invocation, this is the reason that the transaction ID was reset to 0x2 the previous Wireshark screenshot (Figure 2).

After doing a bitwise AND at line #1321, this value is also stored inside “last_id” variable at line #1323. Finally, at line #1335, the value of “local_id” is copied inside the struct resolv\_header “h” variable, which represents the actual content of the header of the DNS request. Similar revisions of this code were found in all versions available of uClibc and uClibc-ng.

**Vulnerability Exploitability**

Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.

If the operating system applies randomization of source port (which is done by all OSs nowadays—for instance, modern Linux kernels use range 32768–60999), exploitability depends on the capacity of the attacker to bruteforce the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response. In this situation, exploitability depends on factors such as the bandwidth at disposal of the attacker, or on the response time of the DNS query. Additionally, it is more likely that an attacker will succeed at least once in performing a DNS poisoning attack if the target device performs a great number of identical queries in a given time frame, compared to a target that performs sporadic queries.

**Mitigations**

This vulnerability remains unpatched, however we are working with the maintainer of the library and the broader community in support of finding a solution.

Because this vulnerability remains unpatched, for the safety of the community we cannot disclose the specific devices we tested on. We can, however, disclose that they were a range of well-known IoT devices running the latest firmware versions with a high chance of them being deployed throughout all critical infrastructure.

We recommend everyone increase their network visibility and security in both IT and OT environments.

**Disclosure Process and Timeline**

As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.

The timeline of events is reported below:

*   2021/09/13: Disclosure to ICS-CERT
*   2021/10/05: Asked for updates from ICS-CERT
*   2021/10/05: Reservation of ticket numbers ICS-VU-638779, VU#473698
*   2021/10/26: Asked for updates from ICS-CERT
*   2021/11/19: Second attempt to ask for updates from ICS-CERT
*   2021/11/29: Received invitation to participate in CERT/CC VINCE case
*   2021/12/08: Request from CERT/CC to validate vulnerability on latest 1.0.39 version, and to provide insights regarding status of disclosure
*   2021/12/09: Replied to CERT/CC, vulnerability confirmed on 1.0.39, informed CERT/CC that for now disclosure has been submitted to ICS-CERT only
*   2021/12/09 (and later): Attempts by CERT/CC to invite uClibc-ng maintainer to the VINCE case
*   2022/01/24: Multiple vendors invited to the VINCE case by CERT/CC, vulnerability disclosed to them
*   2022/02/24: Asked for updates to CERT/CC
*   2022/03/11: Attempt to contact uClibc-ng maintainer
*   2022/03/14: Maintainer confirmed he was contacted by CERT/CC, explained he was unable to fix the vulnerability by himself, explicitly asked to publicly disclose it, hoping for help from the community
*   2022/03/15-16: Discussion with CERT/CC on next steps. Planned to request a second confirmation from the maintainer, then proceed to notification of vendors of a disclosure in 30 days
*   2022/03/18: Asked for second confirmation from maintainer
*   2022/03/21: CERT/CC provided a status update in the VINCE case to vendors
*   2022/03/21-22: Discussion with CERT/CC on next steps
*   2022/03/23: Resent email to maintainer
*   2022/03/29: Proposed to CERT/CC to proceed with the 30-day notification to vendors, given lack of responses (or counter-orders) from maintainer
*   2022/04/01: CERT/CC approved the disclosure schedule proposal
*   2022/04/01: Provided a status update in the VINCE case to vendors, informed them that the vulnerability would be disclosed on May 2nd
*   2022/05/02: Public disclosure

CVE-2022-30295: Nozomi Networks Discovers Unpatched DNS Bug in Popular C Standard Library Putting IoT at Risk

Nozomi Networks Labs discovered a vulnerability (tracked under ICS-VU-638779, VU#473698) affecting the Domain Name System (DNS) implementation of all versions of uClibc and uClibc-ng, a popular C standard library in IoT products. The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.

According to their respective official websites, uClibc is known to be/have been used by major vendors such as Linksys, Netgear, and Axis (only until 2010, newer Axis products include other libraries), as well as Linux distributions such as Embedded Gentoo. uClibc-ng is a fork specifically designed for OpenWRT, a common OS for routers possibly deployed throughout various critical infrastructure sectors.

Because the library maintainer was unable to develop a fix, this vulnerability remains unpatched. For this reason, we are not disclosing the details of the devices on which we were able to reproduce the vulnerability.

In this blog, we start with a background of C Standard Libraries used in IoT devices, present a technical analysis of the issue and detail its exploitability, and then provide a comprehensive timeline of the disclosure process.

A new unpatched vulnerability discovered by Nozomi Networks Labs affects the DNS implementation of all versions of uClibc and uClibc-ng.

**Background: C Standard Libraries and uClibc**

In computing, a library is a collection of resources (functions, configuration data, specifications, etc.) that is shared among software. The purpose of libraries is to provide standard primitives that software can use to perform common operations (such as to access a file on a disk or perform a network operation), without the necessity of reimplementing them all the time.

A C standard library is no exception, in the sense that it is a library for the C programming language itself. A real-world example can be found in the well-known C “Hello, World!” program. When we type the pre-processor command “#include <stdio.h>” and invoke an output function (for instance, “printf”) to print “Hello, World!”, we are actually executing the code of the chosen output function provided by the selected C standard library for the implementation of the header file “stdio.h”.

Of note, uClibc is one of the possible C standard libraries available, and specifically focuses on embedded systems. Other famous C standard libraries are glibc (GNU C library), the musl libc, or the Microsoft C run-time library (CRT).

It’s important to note that a vulnerability affecting a C standard library can be a bit complex. Not only would there be hundreds or thousands of calls to the vulnerable function in multiple points of a single program, but the vulnerability would affect an indefinite number of other programs from multiple vendors configured to use that library.

**Domain Name System (DNS)**

As we know, in modern computer networks the DNS is a hierarchical database that serves the primary, and crucial, purpose of translating a domain name into its related IP address, allowing users to access resources by more easily by memorizing human-friendly names instead of complex sequences of numbers.

Under the hood, DNS requests are mostly transmitted through UDP, which is a connectionless protocol. Thus, in order to distinguish the responses of different DNS requests, besides the usual 5-tuple {source IP, source port, destination IP, destination port, protocol} and of course the query, each DNS request includes a parameter called “transaction ID”. This is a unique number per request that is generated by the client, added in each request sent, and that must be included in a DNS response to be accepted by the client as the valid one for a corresponding request. If this condition is false, the response is discarded; if true (and other checks are satisfied as well), the response is accepted and the program that asked for a translation of a certain domain name can initiate the connection to the IP address provided.

**Figure 1.** Example DNS request. The 5-tuple, txID, and query are highlighted in the red.

Similar to other C standard libraries, uClibc provides an extensive DNS client interface that allows programs to readily perform lookups and other DNS-related requests.

**Poisoning Attacks to DNS**

Because of its relevance, DNS can be a valuable target for attackers. In a DNS poisoning attack, an attacker is able to deceive a DNS client into accepting a forged response, thus inducing a certain program into performing network communications with an arbitrarily defined endpoint, and not the legitimate one. A DNS poisoning attack enables a subsequent Man-in-the-Middle attacks  because the attacker, by poisoning DNS records, is capable of rerouting network communications to a server under their control. The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them. The main issue here is how DNS poisoning attacks can force an authenticated response.

To have a DNS response accepted for a certain DNS request, the aforementioned 5-tuple, the query, and the transaction ID must be correctly set. Given that 1. the protocol is DNS, 2. the destination port is 53/udp, 3. the query is the target that an attacker wants to compromise, 4. the source IP address is the target machine, and 5. the destination IP address is public information (it is the IP address of the DNS server in use in a certain network), the only unknowns remain the source port and the transaction ID. It is vital that these two parameters are as unpredictable as possible, because if they are not, a poisoning attack could be possible. 

**Vulnerability Details**

While we were reviewing the trace of DNS requests performed by an IoT device under test in our lab, we noticed the pattern of DNS requests performed from the output of Wireshark. If you look at the below screenshot (Figure 2) you can see that the transaction ID is first incremental, then resets to the value 0x2, then is incremental again.

**Figure 2.** Trace of DNS requests performed by an IoT device under test

While debugging the related executable, trying to understand the root cause, we eventually noticed that the code responsible for performing the DNS requests was not part of the instructions of the executable itself, but was part of the C standard library in use, namely uClibc 0.9.33.2 (“libuClibc-0.9.33.2.so”).

A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.

**Figure 3.** DNS lookup function of uClibc.

In reference to line #1240, the function declares a static variable “last_id”. This variable contains the value of the transaction ID used in the last DNS request, and is initialized with the value 1 at the first invocation of “__dns_lookup”.

Additionally, at line #1260, the function declares a variable “local_id”. This variable contains the value of the transaction ID that will be used in the upcoming DNS request, and is left uninitialized.

Afterwards, the following lines of code are executed.

**Figure 4.** DNS lookup function of uClibc (2).

In reference to line #1309, at the first DNS request, the “local_id” variable is initialized with the value of the transaction ID of the last DNS request (“last_id”). Line #1320 is the actual core of the vulnerability: “local_id” is updated by incrementing its old value by 1. Given that the value is initialized to 1 at the first invocation, this is the reason that the transaction ID was reset to 0x2 the previous Wireshark screenshot (Figure 2).

After doing a bitwise AND at line #1321, this value is also stored inside “last_id” variable at line #1323. Finally, at line #1335, the value of “local_id” is copied inside the struct resolv\_header “h” variable, which represents the actual content of the header of the DNS request. Similar revisions of this code were found in all versions available of uClibc and uClibc-ng.

**Vulnerability Exploitability**

Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.

If the operating system applies randomization of source port (which is done by all OSs nowadays—for instance, modern Linux kernels use range 32768–60999), exploitability depends on the capacity of the attacker to bruteforce the 16 bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate DNS response. In this situation, exploitability depends on factors such as the bandwidth at disposal of the attacker, or on the response time of the DNS query. Additionally, it is more likely that an attacker will succeed at least once in performing a DNS poisoning attack if the target device performs a great number of identical queries in a given time frame, compared to a target that performs sporadic queries.

**Mitigations**

This vulnerability remains unpatched, however we are working with the maintainer of the library and the broader community in support of finding a solution.

Because this vulnerability remains unpatched, for the safety of the community we cannot disclose the specific devices we tested on. We can, however, disclose that they were a range of well-known IoT devices running the latest firmware versions with a high chance of them being deployed throughout all critical infrastructure.

We recommend everyone increase their network visibility and security in both IT and OT environments.

**Disclosure Process and Timeline**

As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.

The timeline of events is reported below:

*   2021/09/13: Disclosure to ICS-CERT
*   2021/10/05: Asked for updates from ICS-CERT
*   2021/10/05: Reservation of ticket numbers ICS-VU-638779, VU#473698
*   2021/10/26: Asked for updates from ICS-CERT
*   2021/11/19: Second attempt to ask for updates from ICS-CERT
*   2021/11/29: Received invitation to participate in CERT/CC VINCE case
*   2021/12/08: Request from CERT/CC to validate vulnerability on latest 1.0.39 version, and to provide insights regarding status of disclosure
*   2021/12/09: Replied to CERT/CC, vulnerability confirmed on 1.0.39, informed CERT/CC that for now disclosure has been submitted to ICS-CERT only
*   2021/12/09 (and later): Attempts by CERT/CC to invite uClibc-ng maintainer to the VINCE case
*   2022/01/24: Multiple vendors invited to the VINCE case by CERT/CC, vulnerability disclosed to them
*   2022/02/24: Asked for updates to CERT/CC
*   2022/03/11: Attempt to contact uClibc-ng maintainer
*   2022/03/14: Maintainer confirmed he was contacted by CERT/CC, explained he was unable to fix the vulnerability by himself, explicitly asked to publicly disclose it, hoping for help from the community
*   2022/03/15-16: Discussion with CERT/CC on next steps. Planned to request a second confirmation from the maintainer, then proceed to notification of vendors of a disclosure in 30 days
*   2022/03/18: Asked for second confirmation from maintainer
*   2022/03/21: CERT/CC provided a status update in the VINCE case to vendors
*   2022/03/21-22: Discussion with CERT/CC on next steps
*   2022/03/23: Resent email to maintainer
*   2022/03/29: Proposed to CERT/CC to proceed with the 30-day notification to vendors, given lack of responses (or counter-orders) from maintainer
*   2022/04/01: CERT/CC approved the disclosure schedule proposal
*   2022/04/01: Provided a status update in the VINCE case to vendors, informed them that the vulnerability would be disclosed on May 2nd
*   2022/05/02: Public disclosure

The passwordless future just became closer to reality, as Microsoft, Apple, and Google pledge to make the standard possible across operating systems and browsers.

Apple, Google, and Microsoft will expand support for FIDO Alliance's passwordless standard to make logins easier across mobile devices and desktops.

By expanding support for the password-free sign-in standard from the FIDO Alliance and the World Wide Web (W3) Consortium, Google, Microsoft, and Apple will make it possible for anyone to use their mobile device to sign into an app or website on a nearby device. More importantly, users will be able to access passkeys – their FIDO sign-in credentials – across multiple devices without having to re-enroll every account on each device. This will be a key change from the current reality, where users have to sign into each website or app with each device before they can take advantage of the passwordless feature.

"We plan to implement passwordless support for FIDO Sign-in standards in Android & Chrome. Apple and Microsoft have also announced that they will offer support for their platforms," writes Sampath Srinivas, a product management director for secure authentication at Google and the president of the FIDO Alliance. "This will simplify sign-ins across devices, websites, and applications no matter the platform — without the need for a single password. These capabilities will be available over the course of the coming year."

**Case for No More Passwords**  
Passwords do not provide sufficient security – they can be stolen or guessed if the password itself isn't very good. Weak passwords accounted for more than 80% of all data breaches, according to Verizon's annual Data Breach Investigations Report. Passwords are the single largest attack vector and the root cause of most attacks -- including account takeovers, advanced persistent threats, and ransomware, says Jasson Casey, CTO of Beyond Identity. Four out of five times adversaries rely on stolen credentials for initial access and lateral movement, he says.

"Password-based authentication has failed us. Full stop," Casey says.  

There are more than 921 password attacks every second, writes Vasu Jakkal, corporate vice president of security, compliance, identity, and management at Microsoft. That represents more than double the figure over the past 12 months.

A new Google/Ipsos survey found that one in three Americans share passwords with someone else or have access to someone else's passwords, and 65% of respondents say they reuse passwords. One in five use common words or easy-to-guess terms for passwords, and 52% say they incorporate personal information such as name and birthday into the password.

"The alternatives \[to passwords\] often are unworkable, unwieldy, or just not likely to be adopted by consumers, especially the non-tech-savvy ones or those who are on the lower end of the socio-economic scale," says John Bambenek, principal threat hunter at Netenrich.  

Passwords are still ubiquitous despite the issues because they are relatively easy to implement and people know how to use them, which is why passwords still haven't gone away. Instead, security teams rely on technologies such as multifactor authentication and password managers to provide additional protection to strengthen the security around accounts, platforms, and data. 

However, these controls have made "marginal security gains," Casey says, mainly because they still rely on passwords and the second factors can be intercepted via social engineering methods (such as one-time passwords sent over SMS).

**Cross-Platform Passwordless**  
The good news is that technology is now in place to make passwordless authentication a reality, Casey says. Secure enclaves are prevalent (and resident in nearly every device), and almost all enterprise and consumer apps can leverage secure enclaves to easily delegate passwordless authentication.

The announcement from Google, Microsoft, and Apple indicates the expanded support will be implemented in macOS and Safari, Android and Chrome, and Windows and Edge. The actions used to unlock the mobile device — such as fingerprint, face scan, and device PIN — will give access to the passkey stored on the device. Signing in with the passkey is more secure because it's based on public key cryptography, Srinivas says. Even if the device is lost, the passkeys will sync back to the mobile device from cloud backup, he says.

All of this will be cross-platform. Ideally, a user would be able to sign into a website via Google Chrome on a Windows machine using a passkey on an Apple device.

"This new approach protects against phishing and sign-in will be radically more secure when compared to passwords and legacy multi-factor technologies such as one-time passcodes sent over SMS," the FIDO Alliance said in a statement.  

Implementations that rely on secure enclaves, especially those already built into modern devices, such as the Trusted Platform Module on laptops and desktops, combined with the security posture of the device itself make passwordless authentication a reality, Casey says.

Jennifer Easterly, director of the US Cybersecurity and Infrastructure Security Agency (CISA), praises the announcement, calling it "the type of forward-leaning thinking that will ultimately keep the American people safer online."

Passwordless needs to be easy. "If you don’t consider usability, your users will create your next vulnerability," Casey warns.

Microsoft, Apple, and Google Promise to Expand Passwordless Features

PHProjekt PhpSimplyGest and MyProjects version 1.3.0 suffer from a cross site scripting vulnerability.

    # Exploit Title: PHProjekt (PhpSimplyGest / MyProjects, 1.3.0) - Stored XSS (Cross-Site Scripting)# Date: 2022-05-05# Exploit Author: Andrea Intilangelo# Vendor Homepage: http://www.phprojekt.altervista.org (removed demo was at http://phprojekt.altervista.org/phpsimplygest130)# Software Link: https://github.com/robyfofo/MyProjects (original PhpSimplyGest https://github.com/robyfofo/PhpSimplyGest now merged/renamed into MyProjects)# Version: 1.3# Tested on: Latest Version of Desktop Web Browsers (ATTOW: Firefox 100.0, Microsoft Edge 101.0.1210.32)# CVE: CVE-2022-27308Description:A stored cross-site scripting (XSS) vulnerability in PHProjekt PhpSimplyGest v1.3.0 (and related products from same vendor, like "MyProjects") allowsattacker to execute arbitrary web scripts or HTML.Injecting persistent javascript code inside the title description (or content) while creating a project, todo, timecard, estimates, report or finding,it will be triggered once page gets loaded.Steps to reproduce:Click on Projects and add or edit an existing one,Insert the following PoC inside the Title   <<SCRIPT>alert("XSS here");//\<</SCRIPT>Click on 'Send'.If a user visits the website dashboard, as well as project summary page, the javascript code will be rendered.Timeline:2022-01-08: Vulnerability discovered.2022-01-08: Vendor contacted.2022-02-09: No reply, vendor contacted for 2nd time.2022-02-18: Request for CVE reservation.2022-04-27: Assigned CVE number 2022-27308.2022-05-02: No reply, vendor contacted for 3rd time.2022-05-05: Public disclosure.PoC Screenshots:https://imagebin.ca/v/6g5OFET1pyZBhttps://imagebin.ca/v/6g6qLRC3X5kyhttps://postimg.cc/qgc19rg0

PHProjekt PhpSimplyGest / MyProjects 1.3.0 Cross Site Scripting

With 80% of companies using cloud collaboration tools, cybercriminals are using multichannel phishing attacks to exploit security gaps in the hybrid work model.

The modern workforce is hybrid, and remote work is here to stay. With 80% of companies using cloud or hybrid cloud collaboration tools, it's fertile ground for a cybercriminal to expand the threat surface. Multichannel phishing is becoming the preferred way to deliver these attacks as threat actors exploit security gaps in the hybrid work model. While organizations focus on protecting email from phishing and malware, there are gaps in defenses for other channels. In a recent report on how to respond to the cyberthreat landscape, Gartner warns of the use of multichannel phishing approaches that combine social engineering, vishing, smishing, email, and Web phishing attacks in a single campaign.

Today, 91% of all cyber breaches include a phishing attack because these types of attacks often succeed. Cybercriminals are so successful because these attacks are increasingly sophisticated, zero-hour spear-phishing threats designed specifically to slip past traditional security controls Threats to the mobile channel continue to grow with malicious apps, as well as malicious SMS messages with and without malicious links, spear-phishing, and malicious Web content. Mobile devices are an excellent opportunity because they are less protected, URL inspection is harder on mobile devices, phones have smaller screens than computers, and content is often truncated. Cybercriminals take advantage of distracted users who conduct quick work tasks and transactions, which offers the perfect environment for launching multichannel attacks.

Cybercriminals are capitalizing on digital channels that aid the productivity of remote workers like SMS/text, Slack, LinkedIn, Zoom, Microsoft Teams, Google Meet, and WhatsApp. These channels are less protected and provide an easy way to trick users, steal credentials, and ultimately exfiltrate data from an organization. A growing trend for cybercriminals is to use WhatsApp and SMS to send malicious URLs that appear identical to a Microsoft Teams meeting invite, which they use to harvest Microsoft 365 credentials. This benign invite contains a malicious URL that takes the user to a landing page asking them to enter their Microsoft 365 credentials, and, just like that, a user has given up their login credentials. These credentials now enable the cybercriminal to take over an account and continue to deliver phishing attacks from legitimate services like AWS, Azure, Outlook, and SharePoint.

In most cases, these attacks will bypass most phishing detection tools. SlashNext Threat Labs saw a 57% increase in phishing attacks from trusted services from the fourth quarter of 2021 to the first months of 2022. The trusted reputation of these domains enables cybercriminals to easily evade current detection technologies using domain reputation and blocklists like SEG, proxy, SASE, and endpoint security tools. Attackers use shared services to get around domain reputation technologies with increased frequency. Using mainstream, legitimate commercial infrastructure sites to avoid detection has been a successful tactic, and the growth in these threats continues in 2022.

It's long been known that phishing attacks are getting through gaps in current defenses like secure email gateways, advanced threat protection, and identity graph technology. In addition, some users are accessing corporate tools outside of all security defenses. It should be on every cybersecurity leader's list to address multichannel phishing in 2022. So, how do you know if multichannel phishing is a problem in your organization? Start by assessing the phishing attack surface in your organization. Here are a few questions to get started: Where are your employees protected from phishing? Are they protected when accessing URLs on their browser or their mobile device? Are your users protected from zero-hour threats in real time? Answering no to these questions can indicate that your users and the organization are at risk.

A cyber readiness plan to protect against multichannel phishing should include people, processes, and tools. Ensure the plan includes educating users about the risk of multichannel phishing. Communicate about preventative strategies for how to identify social engineering tactics and suspected compromises. Implement an abuse inbox, and enable alerts for suspicious activity, such as foreign logins. Install security tools that leverage AI and computer vision to detect and block malicious zero-hour threats across email, Web, and mobile.

**About the Author**

    

Patrick Harr is CEO of SlashNext, the authority in multichannel phishing and human hacking protection across email, Web, and mobile.

Multichannel Phishing Concerns Cybersecurity Leaders in 2022

Researcher to reveal fresh details at Black Hat Asia on a tenacious cyber-espionage group attacking specific military, law enforcement, aviation, and other entities in Central and South Asia.

It's one of the more prolific yet lesser-known nation-state hacking groups in the world, and it's not out of China or Russia. The so-called SideWinder (aka Rattlesnake or T-APT4) group has been on a tear over the past two years, launching more than 1,000 targeted attacks.

Noushin Shabab, senior security researcher with Kaspersky, has been tracking SideWinder since 2017 and will share her latest findings on this cyber-espionage team at Black Hat Europe in Singapore this month.

"They have been very persistent in their attacks in terms of targeting specific victims over and over, with new malware and newly registered domains," Shabab says. "So even if the target has suspected that a previous attempt had malicious intentions — like with spear-phishing emails and so on — the threat actor has tried to use a new infection vector and use a new domain to try their luck, over and over."

SideWinder also has upped its game when it comes to hiding its tracks and deflecting detection — as well as in thwarting researchers. The threat group now executes a more complex attack chain that uses multiple layers of malware, additional obfuscation, and memory-resident malware that leaves no evidence of its presence, she says. Although other well-oiled and advanced threat groups also continue to add new methods of camouflaging their activity, Noushin says, SideWinder stands apart for her with its dogged persistence and high volume of activity.

"I think what truly makes them stand out among other APT \[advanced persistent threat\] actors is the large toolset they have with many different malware families, lots of new spear-phishing documents, and a very large infrastructure," she says. "I haven't seen 1,000 attacks from a single APT" from another group thus far, she adds. 

Shabab has tracked SideWinder's activity since April 2020, but Kaspersky first reported on SideWinder in January 2018 and believes it's been around since at least 2012. The security firm traditionally avoids attributing threat actors to specific nation-states, but Shabab says her firm's initial research into SideWinder showed the group is tied to an India-based company that was advertising malware analysis and penetration testing services on its website. 

"We found some context between that company and that threat actor," she says. However, she notes that "over the years, \[SideWinder\] attribution became more challenging."

SideWinder mostly targets military and law enforcement entities in Central and South Asia, but it's also hit foreign affairs, defense, aviation, IT, and legal firms in Asia. Pakistan and Sri Lanka are its main focus of late, according to Kaspersky's research, and it's recently targeted government and related organizations in Afghanistan, China, and Nepal, according to previous research from Trend Micro and from Anomaly.

Kaspersky also follows another cyber-spying threat group, dubbed Sidecopy, that copies SideWinder's tactics and techniques on occasion, often pivoting to the newest infection vector SideWinder has adopted. Unlike some other security research teams, Kaspersky considers Sidecopy separate from SideWinder. It's seen Sidecopy target organizations mainly in India and Afghanistan.

**No Zero-Days Required  
**SideWinder's main initial attack vector consists of sending convincing-looking spear-phishing emails with malware-rigged document attachments to its carefully curated targets. The hacking group doesn't deploy any zero-day exploits, but instead mostly weaponizes known Windows or Android vulnerabilities, including old Microsoft Office flaws, according to Shabab.

That said, in January 2020, researchers at Trend Micro revealed that they had discovered SideWinder exploiting a zero-day local privilege-escalation vulnerability that affected hundreds of millions of Android phones when it was first published (CVE-2019-2215).

SideWinder often switches gears if its first attempts don't infect its victims. Shabab has seen the APT abuse the Windows file shortcut feature to mask the malware, for example.

"The interesting thing is we have seen them be quite careful and innovative in the way they approach victims," she says. 

On at least two occasions, she says, SideWinder sent empty document attachments with the spear-phishing emails. The document had no content, but a malicious payload was inside. "After a short while, they send a letter \[in an email\] that apologizes for the empty document they had sent earlier. But that second email had a different malicious payload inside the document," she says. "They were trying everything to make sure they get a foothold into the victim's system."

SideWinder also swaps domains regularly for its command-and-control servers as well as for its download servers. That's mostly to ensure that if a domain gets detected, it still has a way to get to its targets, Shabab explains. Spreading activity across different domains in the attacks is less likely to raise suspicion as well.

Kaspersky's research shows that SideWinder mainly targets Windows for now, but it did find some malicious mobile apps last year when the firm investigated the group's infrastructure domains and servers. 

"But looking at their large attack infrastructure and large malware family sets they have for Windows, it doesn't seem mobile is their main focus," Shabab says.  

**Black Hat Talk  
**Shabab will share technical details in her session at Black Hat Asia next week, entitled "SideWinder Uncoils to Strike." Those will include how the hacking team has evolved its obfuscation methods for hiding its malware, and folding it into multistage infection chains. She says that investigating SideWinder's attack methods required her to decrypt several layers of encryption and thousands of obfuscation scripts. And "for each one, the decryption key was different," she says.

Shabab plans to provide recommendations on how to use SideWinder indicators of compromise along with specific security defense advice on defending against this APT group. Because it mostly achieves initial infections via known vulns and legitimate features in Windows (such as Microsoft Office), patching and the usual best security practices are key. That means hardening applications with whitelisting or firewall rules, which can help halt additional malicious malware modules from SideWinder's servers, she says.

"It's not very difficult to stop the attack" initially, she says. But if SideWinder gets past that first hurdle and infects the machine in the first phase of the attack, eradicating the attack gets exponentially harder. She adds: "They have lots of techniques to stay undetected longer and stay persistent."

1,000+ Attacks in 2 Years: How the SideWinder APT Sheds Its Skin

Google today announced plans to implement support for passwordless logins in Android and the Chrome web browser to allow users to sign in across different devices and websites irrespective of the platform.
"This will simplify sign-ins across devices, websites, and applications no matter the platform - without the need for a single password," Google said.

Apple and Microsoft are

Google today announced plans to implement support for passwordless logins in Android and the Chrome web browser to allow users to sign in across different devices and websites irrespective of the platform.

"This will simplify sign-ins across devices, websites, and applications no matter the platform - without the need for a single password," Google said.

Apple and Microsoft are also expected to extend the support to iOS, macOS, and Windows operating systems as well as Safari and Edge browsers.

The new Fast IDentity Online (FIDO) sign-in system does away with passwords entirely in favor of displaying a prompt asking a user to unlock the phone when signing into a website or an application.

This is made possible by storing a cryptographically secured FIDO credential called a passkey on the phone that's used to log in to the online account after unlocking the device.

"Once you've done this, you won't need your phone again and you can sign-in by just unlocking your computer," Google said.

"Even if you lose your phone, your passkeys will securely sync to your new phone from cloud backup, allowing you to pick up right where your old device left off."

In a way, the method can be viewed as an extension of its own Google prompts for logging into accounts secured with two-factor authentication (aka 2-Step Verification).

The development comes as code hosting platform GitHub announced that it will "require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023" to prevent account takeover attacks.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Google to Add Passwordless Authentication Support to Android and Chrome

By Waqas
Cloudflare explained that it wasn’t the largest application-layer attack but the largest ever noted in the HTTPS category.…
This is a post from HackRead.com Read the original post: Cloudflare Successfully Thwarted One of The Largest DDoS Attacks

Cloudflare explained that it wasn’t the largest application-layer attack but the largest ever noted in the HTTPS category.

Internet Infrastructure company Cloudflare has mitigated one of the world’s largest distributed denial of service attacks (DDoS attacks) recorded to date. According to Cloudflare’s blog post published on April 27th, the company mitigated a 15.3 million rps (request-per-second) DDoS attack earlier in April 2022.

That’s one of the largest HTTPS DDoS attacks recorded so far. It is worth noting that HTTPS DDoS attacks extract more computing power from the device and tend to be more expensive since creating a secure TLS encrypted connection is far costlier than traditional attacks.

> “Therefore it costs the attacker more to launch the attack, and for the victim to mitigate it. We’ve seen very large attacks in the past over (unencrypted) HTTP, but this attack stands out because of the resources it required at its scale,”
> 
> Omer Yoachimik and Julien Desgats – Cloudflare

In August 2021, Cloudflare stopped the largest ever recorded DDoS attack involving 1.72 million HTTP rps. This figure was three times larger than all previously registered volumetric DDoS attacks.

**Volumetric and Bandwidth Attacks**

It is worth noting that volumetric DDoS attacks are different from conventional bandwidth DDoS attacks. In the latter, the attacker tries to exhaust and clog up the internet connection bandwidth of the targeted device.

In contrast, in the former, the attacker focuses on bombarding the victim with as many junk HTTP requests as possible to use up the server CPU and RAM. Moreover, volumetric DDoS attacks prevent other legit users from accessing/visiting the website.

**Details of the Attack**

According to Cloudflare, the victim was its customer using a crypto launchpad that surfaces DeFi (decentralized finance) projects to potential investors. Cloudflare revealed that around 1,300 different networks, including top networks like German provider Hetzner Online GmbH, OVH in France, Azteca Comunicaciones Colombia, and other cloud providers, were used for the attack.

However, the attack lasted less than fifteen seconds and was launched from a botnet comprising 6,000 unique bots originating from 112 countries. 15% of the traffic originated from Indonesia, while other most prominent countries included Russia, Brazil, India, Colombia, and the USA.

Cloudflare didn’t clarify whether the attack was linked to the Emotet botnet, but it did admit that it came from a botnet they have been tracking lately. Another interesting finding Cloudflare shared is that the attack originated from data centers mostly.

**More DDoS Attacks News**

1.  Christian crowdfunding site GiveSendGo hit by DDoS attack
2.  Imperva mitigated a series of massive ransom DDoS attacks
3.  DDoS Attack and Data Wiper Malware hit Computers in Ukraine
4.  Microsoft Azure customer hit by largest ever 3.47 Tbps DDoS attack
5.  DDoS attacks on Minecraft event crippled Internet of a European country

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Cloudflare Successfully Thwarted One of The Largest DDoS Attacks

The vulnerability is 'critical' with a CVSS severity rating of 9.8 out of 10.

The vulnerability is ‘critical’ with a CVSS severity rating of 9.8 out of 10.

Application service provider F5 is warning a critical vulnerability allows unauthenticated hackers with network access to execute arbitrary commands on its BIG-IP systems.

The F5 BIG-IP is a combination of software and hardware that is designed around access control, application availability and security solutions.

The vulnerability is tracked as CVE-2022-1388  with a severity rating of 9.8 out of 10 by the Common Vulnerabilities Scoring System (CVSS) version 3.90.  

According to F5, the flaw resides in the representational state transfer (REST) interface for the iControl framework which is used to communicate between the F5 devices and users.

Threat actors can send undisclosed requests and leverage the flaw to bypass the iControl REST authentication and access the F5 BIG-IP systems, an attacker can execute arbitrary commands, create or delete files or disable servers.

“This vulnerability may allow an unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services,” said F5 in an advisory. “There is no data plane exposure; this is a control plane issue only,” they added.

A self-IP address is an IP address on a BIG-IP system, that a customer uses to associate with VLAN.

The Cybersecurity and Infrastructure Security Agency (CISA) issued an alert and advised users to apply the required updates.

****Affected Versions****

The security vulnerability that affects the BIG-IP product version are:

*   1.0 to 16.1.2
*   1.0 to 15.1.5
*   1.0 to 14.1.4
*   1.0 to 13.1.4
*   1.0 to 12.1.6
*   6.1 to 11.6.5

The F5 will not introduce fixes for versions 11.x (11.6.1 – 11.6.5) and 12.x (12.1.0 – 12.1.6).

The patches for versions v17.0.0, v16.1.2.2, v15.1.5.1, v14.1.4.6, and v13.1.5 were introduced by F5.

The advisory by F5 clarifies that the CVE-2022-1388 has no effect on other F5 products – BIG-IQ Centralized Management, F5OS-A, F5OS-C, or Traffic SDC.

F5 affected products and fixed versions (Source: F5)

The BIG-IP devices are commonly integrated into the enterprises there is a significant threat of widespread attack.

Security researcher Nate Warfield reported in a tweet that nearly 16,000 BIG-IP devices are exposed to the internet. A query shared by Warfield shows the exposed devices on Shodan.

Most of the exposed BIG-IP devices are located in the USA, China, India, and Australia. These systems are allocated to Microsoft corporation, Google LLC, DigitalOcean, and Linode.

****Mitigations****

Three “temporary mitigation” methods were advised by F5, for those who can’t deploy security patches immediately.

According to F5 “You can block all access to the iControl REST interface of your BIG-IP system through self IP addresses”. This can be done by changing the Port Lockdown settings to Allow None for each self-IP address in the system.

Another mitigation method is to restrict iControl REST access through the management interface or modify the BIG-IP httpd configuration.

Additionally, F5 has also released a more generic advisory to tackle another set of 17 high severity vulnerabilities discovered and fixed in BIG-IP.

In July 2020, a critical RCE bug left thousands of F5 BIG-IP users’ accounts vulnerable to an attacker.

Tag

#microsoft