From surveillance to search-and-rescue, consumer drones are having an unprecedented impact on Ukraine’s defense against Russia.

In the snowy streets of the north Ukrainian town of Trostyanets, the Russian missile system fires rockets every second. Tanks and military vehicles are parked on either side of the blasting artillery system, positioned among houses and near the town’s railway system. The weapon is not working alone, though. Hovering tens of meters above it and recording the assault is a Ukrainian drone. The drone isn’t a sophisticated military system, but a small, commercial machine that anyone can buy.

Since Vladimir Putin invaded Ukraine at the end of February, drones of all shapes and sizes have been used by both sides in the conflict. At one end of the scale are large military drones that can be used for aerial surveillance and to attack targets on the ground. In contrast, small commercial drones can be flown by people without any specific training and carried around in a suitcase-sized box. While both types of drones have been used in previous conflicts, the current scale of small, commercial drone use in Ukraine is unprecedented.

Drone videos shared and posted to social media depict the brutality of the war and reveal what has happened during battles. Drones have captured fighting in the destroyed Ukrainian city of Bucha, with lines of tanks moving around streets and troops moving alongside them. Commercial drones have helped journalists document the sheer scale of destruction in Kyiv and Mariupol, flying over burnt-out buildings that have been reduced to rubble.

Russian troops have been caught on camera allegedly shooting at citizens holding their hands in the air. Drone videos show Ukrainian troops shelling Russian positions, monitoring their movements in real time, and ambushing Russian troops. In one video, a drone spots Russian military vehicles leaving troops behind—they run after the transport and fall in the snow. In another, the drone hovers in the air and records a helicopter being shot down as it flies past.

“Drones changed the way the war was supposed to be,” says Valerii Iakovenko, the founder of Ukrainian drone company DroneUA. “It is all about intelligence, collecting and transferring data about enemy troops' movements or positionings, correcting artillery fire. It is about counter-saboteurs' actions, and it is of course search-and-rescue operations.” Iakovenko estimates that Ukrainian forces are operating more than 6,000 drones for reconnaissance and says these can link up with Elon Musk’s Starlink satellite systems to upload footage. “In 2014, drones became the center of attention of intelligence units, but their scale cannot be compared to what we see today,” he says. (Russia first began its invasion of Ukraine in 2014 with its annexation of Crimea.)

Both Ukraine and Russia have used military drones during the war—and Ukraine received donations of drones from the US. These military drones can often fly at high altitudes for long periods of time and fire upon targets, including ships. However, the use of smaller commercial drones in such high numbers stands out, researchers say. These drones, which can sometimes be flimsy and can’t fly far from their operators or stay in the air for long periods, have provided tactical advantages in some cases. (Commercial drones have been used in previous conflicts, for instance in Syria, but not as extensively as in Ukraine.)

A Ukranian serviceman stands next to a downed Russian drone in the area of a research institute, part of Ukraine's National Academy of Science, after a strike, in northwestern Kyiv, on March 22, 2022.

Photograph: ARIS MESSINIS/Getty Images

Civilian drone researcher Faine Greenwood has tracked and logged almost 350 incidents in which consumer drones have been used in Ukraine, with the video footage shared on Twitter, Telegram, YouTube, and other social media. Many of the clips, which Greenwood has also mapped, are recorded by military forces, but others have been captured by civilians and journalists. The documented incidents are likely to be only a small fraction of the drone usage in Ukraine. Iakovenko says that in addition to collecting footage for possible war crimes, drones are being used to inspect buildings that have been hit and to help restore power supplies that have been damaged or knocked out.

“You get cheap airborne surveillance, or even strike capabilities, by using these,” says Ulrike Franke, a senior policy fellow at the European Council on Foreign Relations who has studied the use of drones in war. The drones allow troops on the ground to immediately surveil forces around them, retarget weapons, and take action that could stop enemy advances or save lives. “You have individuals or small militia groups that all of a sudden have their own airborne surveillance capability—that’s something you wouldn’t have had 10 years ago. There certainly have been tactical advances and tactical victories because of that.”

Beyond providing direct surveillance that can contribute to intelligence, the videos being captured by consumer drones could contribute to accountability after the war ends. “This is one of the first cases we have had where drones have collected so much really applicable information for war crimes investigations against civilians,” Greenwood says. Although there are questions about what kinds of footage will be admissible in trials, Greenwood and others are backing up and saving video from drones in Ukraine.

Chief among the commercial drones being used in Ukraine are those from Chinese firm DJI, particularly its Mavic line of devices. Its consumer drones are considered to be some of the easiest to purchase and fly. Both Ukrainian and Russian forces have been seen using the drones, Greenwood says. Early in the war, Ukrainian authorities accused DJI of allowing Russian forces to use its drone detection system to target troops, although the company strongly denies this and no strong evidence has been presented.

At the end of April, DJI announced it was temporarily suspending sales in both Russia and Ukraine. The company has consistently said it doesn’t market its products for military use, and it has refused to enable modifications that would allow such use. “DJI has taken this action not to make a statement about any country, but to make a statement about our principles,” DJI spokesperson Adam Lisberg says. “DJI abhors any use of our drones to cause harm, and we are temporarily suspending sales in these countries in order to help ensure no one uses our drones in combat.”

Despite DJI’s opposition to military uses of its products, the drones have been weaponized during the war. “I don't think people have expected commercial DJI drones to be used at such scale,” says Samuel Bendett, an advisor with nonprofit research organization CNA who focuses on Russia and unmanned and autonomous military systems. “This raises the question of whether drone proliferation can be stopped altogether in any conflict.” Charities, companies, and individuals have donated consumer drones from around the world to Ukrainian forces. (Greenwood says they have seen claims that the Russian military is being supplied with donated drones, too. They also point out Telegram messages that claim to show pro-Russian fighters discussing the use of commercial drones).

While the use of consumer drones in conflicts is not new, the machines are not designed for a hostile environment. “The downside of these drones is that they're not military-grade,” Bendett says, adding they can be targeted by anti-drone technology designed to take them out of the sky. All the drone specialists we spoke to for this article say they haven’t seen as many incidents of drones being shot out of the sky as they would have expected—particularly by Russian forces.

“Flying a simple commercial drone in conflict puts the operators in danger as well,” Bendett says. Civilians, journalists, and humanitarian workers using drones in Ukraine are being put at greater risk when they fly consumer drones, Greenwood adds. “The big problem with consumer drones and conflict zones, which humanitarian aid workers are very conscious of, is that you can't tell them apart; they look exactly the same.” A consumer drone being flown by a civilian appears no different from the same drone being flown by a soldier.

This means there are questions about what will happen under humanitarian laws if people flying drones are targeted, Greenwood says. “What happens if an aid worker is flying a drone and people assume it's a drone, it must be being flown by a combatant, and therefore this is a valid target and I'm going to kill it?”

Small Drones Are Giving Ukraine an Unprecedented Edge

April 2022 saw the arrival of three new ransomware gangs and the unwelcome return of an old enemy.
The post Ransomware: April 2022 review appeared first on Malwarebytes Labs.

The Malwarebytes Threat Intelligence team monitors the threat landscape continuously and produces monthly ransomware reports based on a mixture of proprietary and open-source intelligence.

April 2022 was most notable for the emergence of three new ransomware-as-a-service (RaaS) groups—**Onyx**, **Mindware**, and **Black Basta**—as well as the unwelcome return of **REvil**, one of the world’s most notorious and dangerous ransomware operations.

**An old enemy returns**

**REvil** (aka Sodinokibi) first appeared in May 2020 and has been responsible for numerous high-profile ransomware attacks, including arguably the biggest ransomware attack of all time—a supply-chain attack on Kaseya VSA in July 2021 that is thought to have affected over 1,000 businesses.

REvil disappeared shortly after the Kaseya attack, only to emerge again a few months later, before being forced offline on October 21, 2021, by a multi-country operation. A string of arrests followed, and then in January—in an act of unprecedented co-operation—Russia’s Federal Security Service (FSB) announced that it had dismantled the REvil group and charged its members, thanks to information provided by the USA.

REvil now seems to have returned to the fray with new payloads, and a new leak blog displaying a mixture of new victims and old victims known to have been attacked by REvil.

**New gangs emerge**

**Black Basta** made a name for itself very quickly by coming out of nowhere and carrying out at least eleven successful breaches in April 2022. That ability to perform so many attacks so quickly has led some to speculate that Black Basta is a re-brand of an existing group that already has affiliates.

**Onyx** is a new ransomware gang based on the old Chaos builder. At first, some suspected that Onyx may be a wiper rather than ransomware because it destroyed files larger than 2MB instead of encrypting them. It seems likely that this behavior is the result of a bug in the notoriously poorly-written ransomware builder though.

Another newly-emerged gang is **Mindware**, which appears to have started operations in mid-March using a well-known ransomware strain called SFile2 (aka Escal)—but it was not until April that it began to practice “double extortion”, where data is stolen before it’s encrypted so that victims are faced with the twin threats of data they can’t decrypt, and leaks of sensitive information.

****Ransomware attacks in April 2022****

Malwarebytes Threat Intelligence builds a monthly picture of ransomware activity by monitoring the information published by ransomware gangs on their Dark Web leak sites. This information represents victims who were successfully attacked but opted not to pay a ransom.

****Attacks by ransomware type****

Despite its rapid start, the activities of Black Basta and the other newly-emerged types of ransomware were dwarfed in April by three established threats: LockBit, Conti, and AlphV, which made up 60 percent of all the known breaches in our analysis.

Known ransomware attacks in April 2022 by type of ransomware

Known ransomware attacks in April 2022 by country

Known ransomware attacks in April 2022 by industry

****Ransomware mitigations****

Source: IC3.gov

*   Implement regular backups of all data to be stored as air-gapped, password-protected copies offline. Ensure these copies are not accessible for modification or deletion from any system where the original data resides.
*   Implement network segmentation, such that all machines on your network are not accessible from every other machine.
*   Install and regularly update antivirus software on all hosts, and enable real-time detection.
*   Install updates/patch operating systems, software, and firmware as soon as updates/patches are released.
*   Review domain controllers, servers, workstations, and active directories for new or unrecognized user accounts.
*   Audit user accounts with administrative privileges and configures access controls with the least privilege in mind. Do not give all users administrative privileges.
*   Disable unused remote access/Remote Desktop Protocol (RDP) ports and monitor remote access/RDP logs for any unusual activity.
*   Consider adding an email banner to emails received from outside your organization.
*   Disable hyperlinks in received emails.
*   Use double authentication when logging into accounts or services.
*   Ensure routine auditing is conducted for all accounts.
*   Ensure all the identified IOCs are input into the network SIEM for continuous monitoring and alerts.

****How Malwarebytes protects against ransomware****

Malwarebytes can protect systems against all ransomware variants in several ways.

The Malwarebytes Anti-Malware technology detects malicious files, browser modifications, and system modifications on Windows PCs using a combination of signature-based and signatureless technologies. This layer of protection detects the Ransomware binary itself. Detections can happen in real-time as the binary is run or the infection can be rooted out from an already-compromised machine by conducting a full system scan.

Anti-Ransomware is a signatureless technology in charge of monitoring system activity of processes against a certain subset of data in specific locations on the endpoint. Using patented technology, Anti-Ransomware assesses changes in those data files. If an internal scoring threshold is crossed by a monitored process, it triggers a detection from the Anti-Ransomware component.

For those already infected, Ransomware Rollback can help recover encrypted files within 72 hours of the attack. Rollback creates a local cache on the endpoint to store changes to files on the system. It can use this cache to help revert changes caused by a threat. The rollback feature is dependent on activity monitoring available in Malwarebytes Endpoint Detection and Response.

Ransomware: April 2022 review

The China-based threat actor known as Mustang Panda has been observed refining and retooling its tactics and malware to strike entities located in Asia, the European Union, Russia, and the U.S.
"Mustang Panda is a highly motivated APT group relying primarily on the use of topical lures and social engineering to trick victims into infecting themselves," Cisco Talos said in a new report detailing

The China-based threat actor known as **Mustang Panda** has been observed refining and retooling its tactics and malware to strike entities located in Asia, the European Union, Russia, and the U.S.

"Mustang Panda is a highly motivated APT group relying primarily on the use of topical lures and social engineering to trick victims into infecting themselves," Cisco Talos said in a new report detailing the group's evolving modus operandi.

The group is known to have targeted a wide range of organizations since at least 2012, with the actor primarily relying on email-based social engineering to gain initial access to drop PlugX, a backdoor predominantly deployed for long-term access.

Phishing messages attributed to the campaign contain malicious lures masquerading as official European Union reports on the ongoing conflict in Ukraine or Ukrainian government reports, both of which download malware onto compromised machines.

Also observed are phishing messages tailored to target various entities in the U.S. and several Asian countries like Myanmar, Hong Kong, Japan, and Taiwan.

The findings follow a recent report from Secureworks that the group may have been targeting Russian government officials using a decoy containing PlugX that disguised itself as a report on the border detachment to Blagoveshchensk.

But similar attacks detected towards the end of March 2022 show that the actors are updating their tactics by reducing the remote URLs used to obtain different components of the infection chain.

Other than PlugX, infection chains utilized by the APT group have involved the deployment of custom stagers, reverse shells, Meterpreter-based shellcode, and Cobalt Strike, all of which are used to establish remote access to their targets with the intention of conducting espionage and information theft.

"By using summit- and conference-themed lures in Asia and Europe, this attacker aims to gain as much long-term access as possible to conduct espionage and information theft," Talos researchers said.

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

Experts Uncover New Espionage Attacks by Chinese 'Mustang Panda' Hackers

In WebKitGTK through 2.36.0 (and WPE WebKit), there is a heap-based buffer overflow in WebCore::TextureMapperLayer::setContentsLayer in WebCore/platform/graphics/texmap/TextureMapperLayer.cpp.

CVE-2022-30293: security_advisories/webkitgtk-2.36.0 at master · ChijinZ/security_advisories

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

Vyper is a pythonic smart contract language for the ethereum virtual machine. Since version 0.3.2, decimals use the full range of the underlying int168 type. multiplication of 168 bit integers can wrap in 256-bit arithmetic, but safemul does not check for that. This has been patched in v0.3.4. There are no known workarounds for this issue.

**safemath for decimals do not check for 256-bit overflow**

**Affected versions**

\>=v0.3.2

**Description**

**Impact**

since v0.3.2, decimals use the full range of the underlying int168 type. multiplication of 168 bit integers can wrap in 256-bit arithmetic, but safemul does not check for that.

**Patches****Workarounds****References**

see #2845

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in example link to repo
*   Email us at example email address

CVE-2022-29175

**safemath for decimals do not check for 256-bit overflow**

**Package**

pip vyper ( pip )

**Affected versions**

\>=v0.3.2

**Description**

**Impact**

since v0.3.2, decimals use the full range of the underlying int168 type. multiplication of 168 bit integers can wrap in 256-bit arithmetic, but safemul does not check for that.

**Patches**

to patch in v0.3.4

**Workarounds****References**

tracking in #2845

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in example link to repo
*   Email us at example email address

CVE-2022-29175: Build software better, together

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.

Tag

#mac