Three tech giants used World Password Day to announce their commitment to a passwordless future using FIDO Alliance standards.
The post Google, Apple, and Microsoft step hand in hand into a passwordless future appeared first on Malwarebytes Labs.

While we recently “celebrated” World Password Day, almost every security outlet keeps telling us that passwords alone are not enough.

In practice, in the last few years this has meant pairing passwords with something else, such as a one-time code from an app or an SMS message, in a scheme called two-factor authentication (2FA).

But while pairing passwords with a second factor is much better than using a password by itself, it is just a way of working around some very serious, inherent flaws in password authentication. Which begs the question: If passwords are such a problem, why use them at all?

Now Apple, Google and Microsoft have announced that you don’t have to.

The trio of tech giants all used World Password Day to declare increased support for FIDO Alliance standards like FIDO2, a globally-recognized standard for passwordless authentication.

According to the alliance:

> In a joint effort to make the web more secure and usable for all, Apple, Google and Microsoft today announced plans to expand support for a common passwordless sign-in standard created by the FIDO Alliance and the World Wide Web Consortium. The new capability will allow websites and apps to offer consistent, secure, and easy passwordless sign-ins to consumers across devices and platforms.

**Microsoft, Google, and Apple**

Last year, Microsoft announced that as of September 15, 2021 you can completely remove the password from your Microsoft account and use the Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email to sign in to Microsoft apps and services.

On May 5, 2022, Google announced it will implement passwordless support in Android and Chrome, and Apple announced its support for new authentication capabilities enabled by the adoption of FIDO’s latest standard.

The expanded standards-based capabilities will give websites and apps the ability to offer an end-to-end passwordless option. Users will sign in through the same action that they take multiple times each day to unlock their devices, such as a simple verification of their fingerprint or face, or a device PIN.

With all three tech giants on board, we can expect passwordless FIDO sign-in across macOS and Safari; Android and Chrome; and Windows and Edge. This means that, for example, users will be able to sign in on a Google Chrome browser that’s running on Microsoft Windows, using a passkey on an Apple device.

**FIDO2**

Instead of using a password, which can be intercepted as it passes over the Internet, and has to be processed and stored by each service you use, FIDO2 uses public-key encryption. It performs the cryptographic operation that verifies who you are on a device you own, using a private key that never leaves your possession. This means that nothing of value is shared with or stored on the website or service you’re using, and the information sent back and forth during authentication is of no use to an attacker.

FIDO2 combines two standards: WebAuthn and CTAP. WebAuthn does the important job of setting out how web browsers authenticate to websites, but the real magic of FIDO2 is CTAP, the Client to Authenticator Protocol.

CTAP is what allows that crucial cryptographic operation to happen on a wide variety of devices (referred to as “roaming authenticators”), including hardware keys, phones, and laptops. These roaming authenticators are expected to have a mechanism to obtain a “user gesture” which authorises the cryptographic operation, such as a consent button, a password, a PIN, a fingerprint, or face recognition. And this is what allows you to approve your authentication to a website using your iPhone’s Touch ID or Windows Hello.

Devices that act as roaming authenticators can also communicate with other devices, so you can do things like signing in to websites you’re visiting on your laptop by using Touch ID on your iPhone or drawing a pattern on your Android tablet.

**Will it work?**

The idea of passwordless authentication is to create a login method that is secure and easy-to-use, and that eliminates the risks of phishing, password guessing, password reuse, and credential stuffing.

As with all security innovations, we don’t expect attackers to respond by giving up and going home, just to shift their attention to (hopefully) more difficult and expensive forms of attack.

When Microsoft announced in September that you no longer needed a password, we spoke to Per Thorsheim, one of the world’s leading experts on passwords. He had some major concerns about situations when people lose access to their choice of authenticator, and with that lose access to their Microsoft account.

> \[I am concerned about\] when people lose access to their choice of authenticator, and by that lose access to their Microsoft account. I’ve attempted account recovery with Microsoft before, and I know others who have tried and failed miserably. Account recovery is hard, usually to avoid making the process a prime target for hackers.

FIDO2 puts a heavy burden on the account recovery process. Will there be a backup method similar to a “forgot my password” procedure, or do I have to create a new account which can then be linked to my online persona? Either way, such a method could create create a backdoor for attackers to target instead of FIDO-protected authentication.

Passwordless authentication could also multiply the stress caused by a stolen or lost device. If an attacker can guess your PIN or pattern they have access to all of your accounts.

Fortunately, rate-limits on phones makes that very difficult. Even if you secure your device with a 4-digit PIN or a pattern, an attacker finding or stealing your device will have to be very lucky to guess it correctly before the device shuts them out altogether.

However, trusting someone with the access code to your phone will become the equivalent of handing them the key to your entire online life.

If the importance of device access increases, this could lead to more stringent authentication requirements on our pohnes. For example, PINs with 10 digits instead of four or six, or more complicated patterns. And perhaps we’ll say goodbye to default PINs as well.

Nevertheless, we look forward to the passwordless future, even if we may have to work out some details along the way. Passwords have outlived their use for important resources: Victims have been made despite doing everything right; and threat actors have made an industry out of phishing our passwords, keyphrases, and security questions, and from brute-force guessing our passwords.

It is time for something new and three tech giants working together with an established industry association on a passwordless future looks promising.

Stay safe, everyone!

Google, Apple, and Microsoft step hand in hand into a passwordless future

Apple, Google and Microsoft announced this week they will soon support an approach to authentication that avoids passwords altogether, and instead requires users to merely unlock their smartphones to sign in to websites or online services. Experts say the changes should help defeat many types of phishing attacks and ease the overall password burden on Internet users, but caution that a true passwordless future may still be years away for most websites.

**Apple**, **Google** and **Microsoft** announced this week they will soon support an approach to authentication that avoids passwords altogether, and instead requires users to merely unlock their smartphones to sign in to websites or online services. Experts say the changes should help defeat many types of phishing attacks and ease the overall password burden on Internet users, but caution that a true passwordless future may still be years away for most websites.

Image: Blog.google

The tech giants are part of an industry-led effort to replace passwords, which are easily forgotten, frequently stolen by malware and phishing schemes, or leaked and sold online in the wake of corporate data breaches.

Apple, Google and Microsoft are some of the more active contributors to a passwordless sign-in standard crafted by the FIDO (“Fast Identity Online”) Alliance and the World Wide Web Consortium (W3C), groups that have been working with hundreds of tech companies over the past decade to develop a new login standard that works the same way across multiple browsers and operating systems.

According to the FIDO Alliance, users will be able to sign in to websites through the same action that they take multiple times each day to unlock their devices — including a device PIN, or a biometric such as a fingerprint or face scan.

“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 alliance wrote on May 5.

**Sampath Srinivas**, director of security authentication at Google and president of the FIDO Alliance, said that under the new system your phone will store a FIDO credential called a “passkey” which is used to unlock your online account.

“The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone,” Srinivas wrote. “To sign into a website on your computer, you’ll just need your phone nearby and you’ll simply be prompted to unlock it for access. Once you’ve done this, you won’t need your phone again and you can sign in by just unlocking your computer.”

As _ZDNet_ notes, Apple, Google and Microsoft already support these passwordless standards (e.g. “Sign in with Google”), but users need to sign in at every website to use the passwordless functionality. Under this new system, users will be able to automatically access their passkey on many of their devices — without having to re-enroll every account — and use their mobile device to sign into an app or website on a nearby device.

**Johannes Ullrich**, dean of research for the SANS Technology Institute, called the announcement “by far the most promising effort to solve the authentication challenge.”

“The most important part of this standard is that it will not require users to buy a new device, but instead they may use devices they already own and know how to use as authenticators,” Ullrich said.

**Steve Bellovin**, a computer science professor at Columbia University and an early internet researcher and pioneer, called the passwordless effort a “huge advance” in authentication, but said it will take a very long time for many websites to catch up.

Bellovin and others say one potentially tricky scenario in this new passwordless authentication scheme is what happens when someone loses their mobile device, or their phone breaks and they can’t recall their iCloud password.

“I worry about people who can’t afford an extra device, or can’t easily replace a broken or stolen device,” Bellovin said. “I worry about forgotten password recovery for cloud accounts.”

Google says that 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.”

Apple and Microsoft likewise have cloud backup solutions that customers using those platforms could use to recover from a lost mobile device. But Bellovin said much depends on how securely such cloud systems are administered.

“How easy is it to add another device’s public key to an account, without authorization?” Bellovin wondered. “I think their protocols make it impossible, but others disagree.”

**Nicholas Weaver**, a lecturer at the computer science department at **University of California, Berkeley**, said websites still have to have some recovery mechanism for the “you lost your phone and your password” scenario, which he described as “a really hard problem to do securely and already one of the biggest weaknesses in our current system.”

“If you forget the password and lose your phone and can recover it, now this is a huge target for attackers,” Weaver said in an email. “If you forget the password and lose your phone and CAN’T, well, now you’ve lost your authorization token that is used for logging in. It is going to have to be the latter. Apple has the infrastructure in place to support it (iCloud keychain), but it is unclear if Google does.”

Even so, he said, the overall FIDO approach has been a great tool for improving both security and usability.

“It is a really, really good step forward, and I’m delighted to see this,” Weaver said. “Taking advantage of the phone’s strong authentication of the phone owner (if you have a decent passcode) is quite nice. And at least for the iPhone you can make this robust even to phone compromise, as it is the secure enclave that would handle this and the secure enclave doesn’t trust the host operating system.”

The tech giants said the new passwordless capabilities will be enabled across Apple, Google and Microsoft platforms “over the course of the coming year.” But experts said it will likely take several more years for smaller web destinations to adopt the technology and ditch passwords altogether.

Recent research shows far too many people still reuse or recycle passwords (modifying the same password slightly), which presents an account takeover risk when those credentials eventually get exposed in a data breach. A report in March from cybersecurity firm **SpyCloud** found 64 percent of users reuse passwords for multiple accounts, and that 70 percent of credentials compromised in previous breaches are still in use.

A March 2022 white paper on the FIDO approach is available here (PDF). A FAQ on it is here.

Your Phone May Soon Replace Many of Your Passwords

By Deeba Ahmed
The malware Raspberry Robin is distributed via external drives and uses Microsoft Standard installer to execute malicious commands.…
This is a post from HackRead.com Read the original post: USB-based Wormable Raspberry Robin Malware Targeting Windows Installer

The malware Raspberry Robin is distributed via external drives and uses Microsoft Standard installer to execute malicious commands.

Red Canary’s Detection Engineering team has discovered a new worm-like Windows malware being distributed via removable USB drives. The malware was detected in several customer networks, mainly in the manufacturing and technology sectors.

**About Raspberry Robin**

Red Canary intelligence analysts attributed the malware to the Raspberry Robin cluster, noting that the worm leverages “Windows Installer” to access QNAP-linked domains and download a malicious DLL.

Raspberry Robin’s activity was first documented in September 2021. The operator’s objective is unclear, and researchers are also clueless about when and how the external drives get infected. They suspect that this infection occurs offline.

**Attack Chain Details**

> Raspberry Robin’s attack chain starts with connecting an infected external/USB drive to a Windows device. Researchers noted that adversaries use msiexec.exe to deliver malware while “Raspberry Robin uses msiexec.exe to attempt external network communication to a malicious domain for C2 purposes.
> 
> Lauren Podber and Stef Rand  
> Red Canary

The external drive is equipped with the worm payload that appears as a .LNK shortcut file in a legit folder. The worm creates a new process using cmd.exe to read/execute the malicious file on the USB drive.

According to Red Canary’s blog post, once this is done, the worm launches explorer.exe and msiexec.exe. The latter is used to establish network communication with a rogue domain and for downloading/installing the DLL library file.

Raspberry Robin event outline (Red Canary)

This DLL file is loaded and executed using legitimate Windows utilities like rundll32.exe, fodhelper.exe, and odbcconf.exe to bypass the UAC (User Account Control). Researchers also detected an outbound C2 contact involving regsvr32.exe, dllhost.exe, and rundll32.exe processes to IP addresses linked with Tor nodes.

Regarding why the worm installs a malicious DLL, the researchers were unclear. They hypothesized that it could be done to maintain persistence on the infected machine.

**More Windows Malware News**

1.  Beware of Fake Windows 11 Update Delivering Malware
2.  LodaRAT Windows malware now hunting Android devices
3.  New malware tool can steal files from air-gapped PCs using USBs
4.  PyMICROPSIA Windows malware steals browsing data, records audio
5.  Fake Windows website dropped Redline malware as Windows 11 upgrade

USB-based Wormable Raspberry Robin Malware Targeting Windows Installer

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between April 29 and May 6. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics,...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

Threat Roundup for April 29 to May 6

By Deeba Ahmed
Attackers from the Ukrainian IT army successfully disrupted alcohol shipments in Russia by targeting EGAIS, the country’s primary…
This is a post from HackRead.com Read the original post: DDoS Attacks by Hacktivists Disrupted Russian Alcohol Supply Chain

Attackers from the Ukrainian IT army successfully disrupted alcohol shipments in Russia by targeting EGAIS, the country’s primary online portal for alcohol distribution.

According to Russian news portal Vedomosti, Ukrainian hacktivists took down Russia’s central alcohol distribution platform called Unified State Automated Alcohol Accounting Information System or EGAIS, with DDoS attacks launched on May 2nd and 3rd.

EGAIS is an important portal since, as per the law, all alcohol producers and distributors must register their shipments at EGAIS. Therefore, an attack on this platform caused extensive service blockage across Russia.

**Details of the Attack**

Reportedly, three sites belonging to the platform received DDoS attacks. When checked on May 4th, two EGAIS sites gave the error “the server stopped responding,” and the third didn’t work.

The attacks began on May 2nd and the next day system failures became more obvious. Wine trader Fort claimed that service disruption occurred on May 4th while the Union of Alcohol Producers, Igor Kosarev, and Ladoga representative claimed the same.

Fort’s executive director, Alexander Lipilin, stated that 70% of the invoices failed to be uploaded to EGAIS on May 4th. Strong alcoholic beverages producer Beluga Group didn’t report any problems with EGAIS.

The problem got partially resolved on the morning of May 4th. Out of the 1,500 documents queued in Ladoga, 600 were sent to the system. The problem is expected to be fully fixed within the next two days.

CIFFRA (Center for Research on Federal and Regional Alcohol Markets) director, Vadim Drobiz, stated that the EGAIS attack didn’t affect the end consumer as stores had stocked alcohol before the holidays.

**Widespread Impact of the Attack**

The entire EGAIS system got paralyzed, and as a result, the alcohol supply chain was disrupted during the May holidays. Vedomosti further noted that the DDoS attacks continued until May 4th, due to which manufacturers and suppliers couldn’t contact technical support to address delays or fix invoices and complete orders.

According to Russian news portal Vedomosti, shipments to retail chains failed for many companies; factories didn’t receive a tank full of alcohol while restaurants couldn’t upload receipts. 

> “Due to a large-scale failure, factories cannot accept tanks with alcohol, and customers, stores, and distributors cannot receive finished products that have already been delivered to them,” Vedomosti reported.

One of the companies impacted by the closure of the EGAIS portal announced to suspend all purchases as its warehouses were full. The outage mainly affected Vodka distribution, but wine companies also reported service disruption.

**Ukrainian Hacktivists Claim Responsibility**

Ukrainian hacktivists, particularly the Disbalancer group, claimed responsibility for the attack and announced their plans to launch more attacks on the platform. It is worth noting that the Ukrainian IT Army earlier announced to target EGAIS servers on its Telegram channel, including the portals check.egais.ru, egais.ru, and service.egais.ru. 

Ukrainian IT Army is a special cyber force that recruits volunteers from across the globe to launch cyberattacks against Russian infrastructure/entities.

**More DDoS Attack Stories**

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.  Cloudflare Successfully Thwarted One of The Largest DDoS Attacks
5.  Microsoft Azure customer hit by largest ever 3.47 Tbps DDoS attack
6.  DDoS attacks on Minecraft event crippled the Internet of a European country

DDoS Attacks by Hacktivists Disrupted Russian Alcohol Supply Chain

For most of us, passwords are the most visible security control we deal with on a regular basis, but we are not very good at it.

Whether we as a whole are doing better or worse in terms of password security is still unclear, but one thing is certain: We are clearly overconfident in our perceptions about our security activities.  

With adversaries increasingly targeting passwords to break into online accounts or gain access to corporate networks, people are both more aware about password security yet not doing enough to secure their credentials. Two-thirds of respondents (66%) in a recent password security survey conducted by Ipsos on behalf of Google said they use completely random passwords with a mix of characters, but 65% also said they reuse passwords for different online accounts.

There is some indication that users are using technology to improve password security: Sixty-one percent of respondents said they sign into sites using another service (such as Apple ID or Google accounts), according to the Google/Ipsos survey, and 44% said they use a password manager service. Yet 63% said they track passwords by writing them down on paper or making a note on their mobile devices.   

**Who Has 2FA?  
**Two-factor authentication (2FA) is another head-scratcher. Almost three-quarters (73%) of respondents say they use 2FA at least some of the time, but the adoption numbers from individual services tell a different story. Just 2.5% of active Twitter accounts had at least one 2FA method enabled as of June 2021, according to the social media company’s transparency report. Only 16.5% of active GitHub users and 6.44% of npm users have enabled one or more forms of 2FA on their accounts, according to Microsoft-owned GitHub. 

Perhaps the figures indicating a high rate of adoption for multifactor authentication (MFA) are skewed by the gamers on platforms that offer incentives to enable them. In a 2019 study on adoption rates for 2FA, 56.7% of the respondents had a Blizzard account, of which 43.1% had activated 2FA authentication; 88.1% had a Steam account, of which 62.6% had activated 2FA; and 65.6% had a Guild Wars 2 account, of which 55% had activated 2FA. Compare that to 87.7% of respondents who had a Reddit account, but only 11.5% had activated 2FA.

There is a bit of a disconnect on the corporate side, too. In a recent study on identity management by ESG, 58% of organizations said they have implemented MFA, while 23% ranked MFA as the most effective identity and access management solution. Yet Microsoft said in its Cyber Signals report earlier this year that only 22% of all its Azure Active Directory customers use MFA.

In the same ESG report, 32% of organizations said they make MFA optional for employees, and 27% treat MFA as optional for third-party contractors and workers.

The post-mortem investigation of the ransomware incident at Colonial Pipeline found the attack succeeded because the compromised account did not have MFA enabled, says Bojan Simic, CEO and CTO of HYPR. In fact, while defense contractors should have also implemented MFA five years ago, many have not fully implemented it.

“MFA projects frequently exist on a planning chart only,” Simic says.

Passwords: Do Actions Speak Louder Than Words?

NCSC proposes new code of conduct for app stores

NCSC proposes new code of conduct for app stores

  

A report from the UK government has laid bare the risks of malicious mobile apps, as lawmakers call for tougher protections for consumers.

The report (PDF), published by the UK National Cyber Security Centre (NCSC), found that “people’s data and money are at risk because of fraudulent apps containing malicious malware created by cybercriminals or poorly developed apps which can be compromised by hackers exploiting weaknesses in software”.

The study, which conducted a review into the app store ecosystem from December 2020 to March 2022, detailed how 87% of UK citizens now own a smartphone, conveying a widespread attack surface.

Read more of the latest security news from the UK

“\[M\]alicious and poorly developed apps continue to be accessible to users, therefore it is evident that some developers are not following best practice when creating apps,” the NCSC claims.

“Additionally, prominent app store operators are not adequately signposting app requirements to developers and providing detailed feedback if an app or update is rejected.”

**New rules**

In response to the findings, the government is calling views from the tech industry on enhanced security and privacy requirements for firms running app stores and developers making apps.

Under new proposals, app stores for smartphones, game consoles, TVs and other smart devices could be asked to commit to a new code of practice setting out baseline security and privacy requirements, which the UK says “would be the first such measure in the world”.

RELATED UK government reveals plans to become ‘global cyber power’ in 2022

Developers and store operators making apps available to UK users would be covered including Apple, Google, Amazon, Huawei, Microsoft, and Samsung.

The proposed policy would require stores to have a vulnerability reporting process for each app available. They would also be required to share more security and privacy information in an accessible way, including giving consumers information on matters such as why an app would need access to users’ contacts and location.

NCSC technical director Ian Levy commented: “Our threat report shows there is more for app stores to do, with cybercriminals currently using weaknesses in app stores on all types of connected devices to cause harm.

“I support the proposed code of practice, which demonstrates the UK’s continued intent to fix systemic cybersecurity issues.”

**‘Crucial awareness’**

Filip Verloy, EMEA technical evangelist at Noname Security, commented: “These types of initiatives raise crucial awareness of the security issues that we currently face and provide a healthy and necessary debate on the subject. This should prove useful even if it only accomplishes just that.

“However, there are a few flaws to the measures proposed. Firstly, Apple has already made it a point of differentiation to prioritize privacy and security and perform extensive moderation in their app store versus competitors.

“Secondly, there is no such thing as 100% certainty about security when it comes to software, though laying out best practices and increasing scrutiny will certainly help weed out the worst offenders.”

YOU MAY ALSO LIKE UK government employees receive ‘billions’ of malicious emails per year – report

UK government calls for tougher protections against malicious mobile apps

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

Tag

#microsoft