Under certain circumstances, a vulnerability in Metasys ADS/ADX/OAS 10 versions prior to 10.1.5 and Metasys ADS/ADX/OAS 11 versions prior to 11.0.2 could allow a user to inject malicious code into the MUI Graphics web interface.

CVE-2022-21938: Product Security Advisories

Local privilege vulnerability in Yandex Browser for Windows prior to 22.3.3.801 allows a local, low privileged, attacker to execute arbitary code with the SYSTEM privileges through manipulating temporary files in directory with insecure permissions during Yandex Browser update process.

Security WiFi bypass in Yandex Browser from version 15.10 to 15.12 allows remote attacker to sniff traffic in open or WEP-protected wi-fi networks despite of special security mechanism is enabled.

Yandex Protect Anti-phishing warning in Yandex Browser for desktop from version 15.12.0 to 16.2 could be used by remote attacker for brute-forcing passwords from important web-resource with special JavaScript.

Yandex Protect Anti-phishing warning in Yandex Browser for desktop from version 16.7 to 16.9 could be used by remote attacker for brute-forcing passwords from important web-resource with special JavaScript.

CSRF of synchronization form in Yandex Browser for desktop before version 16.6 could be used by remote attacker to steal saved data in browser profile.

XSS in Yandex Browser BookReader in Yandex browser for desktop for versions before 16.6. could be used by remote attacker for evaluation arbitrary javascript code.

XSS in Yandex Browser Translator in Yandex browser for desktop for versions from 15.12 to 16.2 could be used by remote attacker for evaluation arbitrary javascript code.

Yandex Browser for iOS before 16.10.0.2357 does not properly restrict processing of facetime:// URLs, which allows remote attackers to initiate facetime-call without user's approval and obtain video and audio data from a device via a crafted web site.

Yandex Browser for desktop before 17.1.1.227 does not show Protect (similar to Safebrowsing in Chromium) warnings in web-sites with special content-type, which could be used by remote attacker for prevention Protect warning on own malicious web-site.

Yandex Browser before 16.9.0 allows remote attackers to spoof the address bar via window.open.

Race condition issue in Yandex Browser for Android before 17.4.0.16 allowed a remote attacker to potentially exploit memory corruption via a crafted HTML page.

Yandex Browser installer for Desktop before 17.4.1 has a DLL Hijacking Vulnerability because an untrusted search path is used for dnsapi.dll, winmm.dll, ntmarta.dll, cryptbase.dll or profapi.dll.

Yandex Browser before 20.8.4 allows remote attackers to spoof the address bar.

Kirtikumar Anandrao Ramchandani

Yandex Browser Lite before 20.10.0 allows remote attackers to spoof the address bar.

Kirtikumar Anandrao Ramchandani

Yandex Browser Lite for Android before 21.1.0 allows remote attackers to spoof the address bar.

Kirtikumar Anandrao Ramchandani

Yandex Browser Lite for Android prior to version 21.1.0 allows remote attackers to cause a denial of service.

Kirtikumar Anandrao Ramchandani

Yandex Browser for Android prior to version 21.3.0 allows remote attackers to perform IDN homograph attack.

Kirtikumar Anandrao Ramchandani

An elevation of privilege vulnerability exists in Yandex Browser prior to 22.5.0.826.

An elevation of privilege vulnerability exists in Yandex Browser prior to 21.9.0.390.

An elevation of privilege vulnerability exists in Yandex Browser prior to 22.3.3.801.

An elevation of privilege vulnerability exists in Yandex Browser prior to 22.3.3.684.

CVE-2022-28226: Яндекс Охота в Браузере

In onCreateContextMenu of NetworkProviderSettings.java, there is a possible way for non-owner users to change WiFi settings due to a missing permission check. This could lead to local escalation of privilege with User execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-12 Android-12LAndroid ID: A-206986392

_Published June 6, 2022 | Updated June 7, 2022_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2022-06-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available.

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2022-06-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-06-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39691

A-157929241

EoP

High

10, 11, 12

CVE-2022-20006

A-151095871

EoP

High

10, 11, 12, 12L

CVE-2022-20125

A-194402515

EoP

High

10, 11, 12, 12L

CVE-2022-20138

A-210469972 \[2\]

EoP

High

10, 11, 12, 12L

CVE-2021-39624

A-67862680

DoS

High

10, 11, 12, 12L

**Media Framework**

The vulnerability in this section could lead to remote code execution with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20130

A-224314979

RCE

Critical

10, 11, 12, 12L

**System**

The most severe vulnerability in this section could lead to remote code execution with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20127

A-221862119

RCE

Critical

10, 11, 12, 12L

CVE-2022-20140

A-227618988

EoP

Critical

12, 12L

CVE-2022-20145

A-201660636

EoP

Critical

11

CVE-2022-20124

A-170646036

EoP

High

10, 11, 12, 12L

CVE-2022-20126

A-203431023

EoP

High

10, 11, 12, 12L

CVE-2022-20133

A-206807679

EoP

High

10, 11, 12, 12L

CVE-2022-20134

A-218341397 \[2\]

EoP

High

10, 11, 12, 12L

CVE-2022-20135

A-220303465

EoP

High

10, 11, 12, 12L

CVE-2022-20137

A-206986392

EoP

High

12, 12L

CVE-2022-20142

A-216631962

EoP

High

10, 11, 12, 12L

CVE-2022-20144

A-187702830 \[2\]

EoP

High

10, 11, 12, 12L

CVE-2022-20147

A-221216105

EoP

High

10, 11, 12, 12L

CVE-2022-20123

A-221852424

ID

High

10, 11, 12, 12L

CVE-2022-20131

A-221856662

ID

High

10, 11, 12, 12L

CVE-2022-20129

A-217934478 \[2\]

DoS

High

10, 11, 12, 12L

CVE-2022-20143

A-220735360

DoS

High

10, 11, 12, 12L

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Component

CVE

Media Codecs

CVE-2022-20130

**2022-06-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-06-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Kernel components**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Component

CVE-2021-4154

A-218836280  
Upstream kernel

EoP

High

Kernel

CVE-2022-20141

A-112551163  
Upstream kernel

EoP

High

Inet sockets

CVE-2022-24958

A-220261709  
Upstream kernel \[2\] \[3\] \[4\]

EoP

High

USB

CVE-2022-25258

A-222023189  
Upstream kernel \[2\]

EoP

High

USB

CVE-2022-20132

A-188677105  
Upstream kernel \[2\] \[3\] \[4\] \[5\] \[6\] \[7\]

ID

High

USB HID

CVE-2022-25375

A-162326603  
Upstream kernel

ID

High

RNDIS driver

**MediaTek components**

This vulnerability affects MediaTek components and further details are available directly from MediaTek. The severity assessment of this issue is provided directly by MediaTek.

   

CVE

References

Severity

Component

CVE-2022-21745  

A-228972609  
M-ALPS06468872\*

High

WIFI Firmware

**Unisoc components**

This vulnerability affects Unisoc components and further details are available directly from Unisoc. The severity assessment of this issue is provided directly by Unisoc.

   

CVE

References

Severity

Component

CVE-2022-20210  

A-228868888  
U-1770644\*

Critical

Modem

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2021-35083  

A-209481130\*

High

Closed-source component

CVE-2021-35102  

A-209469926\*

High

Closed-source component

CVE-2021-35111  

A-209469960\*

High

Closed-source component

CVE-2022-22082

A-223211217\*

High

Closed-source component

CVE-2022-22083

A-223210917\*

High

Closed-source component

CVE-2022-22084  

A-223209816 \*

High

Closed-source component

CVE-2022-22085

A-223209306\*

High

Closed-source component

CVE-2022-22086

A-223211218\*

High

Closed-source component

CVE-2022-22087

A-223209610\*

High

Closed-source component

CVE-2022-22090

A-223210918\*

High

Closed-source component

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2022-06-01 or later address all issues associated with the 2022-06-01 security patch level.
*   Security patch levels of 2022-06-05 or later address all issues associated with the 2022-06-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2022-06-01\]
*   \[ro.build.version.security\_patch\]:\[2022-06-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-06-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2022-06-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2022-06-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

June 6, 2022

Bulletin Published

1.1

June 7, 2022

Bulletin revised to include AOSP links

CVE-2022-20137: Android Security Bulletin—June 2022  |  Android Open Source Project

In occupied Ukraine, people’s internet is being routed to Russia—and subjected to its powerful censorship and surveillance machine.

Web pages in the city of Kherson in south Ukraine stopped loading on people’s devices at 2:43 pm on May 30. For the next 59 minutes, anyone connecting to the internet with KhersonTelecom, known locally as SkyNet, couldn’t call loved ones, find out the latest news, or upload images to Instagram. They were stuck in a communications blackout. When web pages started stuttering back to life at 3:42 pm, everything appeared to be normal. But behind the scenes everything had changed: Now all internet traffic was passing through a Russian provider and Vladimir Putin’s powerful online censorship machine.

Since the end of May, the 280,000 people living in the occupied port city and its surrounding areas have faced constant online disruptions as internet service providers are forced to reroute their connections through Russian infrastructure. Multiple Ukrainian ISPs are now forced to switch their services to Russian providers and expose their customers to the country’s vast surveillance and censorship network, according to senior Ukrainian officials and technical analysis viewed by WIRED.

The internet companies have been told to reroute connections under the watchful eye of Russian occupying forces or shut down their connections entirely, officials say. In addition, new unbranded mobile phone SIM cards using Russian numbers are being circulated in the region, further pushing people towards Russian networks. Grabbing control of the servers, cables, and cell phone towers—all classed as critical infrastructure—which allow people to freely access the web is considered one of the first steps in the “Russification” of occupied areas.

“We understand this is a gross violation of human rights,” Victor Zohora, the deputy head of Ukraine’s cybersecurity agency, known as the State Services for Special Communication and Information Protection (SSSCIP), tells WIRED. “Since all traffic will be controlled by Russian special services, it will be monitored, and Russian invaders will restrict the access to information resources that share true information.”

KhersonTelecom first switched its internet traffic to a Russian network on April 30, before flipping back to Ukrainian connections for the majority of May. However, things appear to have shifted permanently since May 30. All of KhersonTelecom’s traffic is now being routed through Miranda Media, a Crimea-based company that’s itself connected to Russian national telecom provider Rostelecom. (Miranda Media was set up after Putin annexed Crimea in 2014). The day after KhersonTelecom made its latest switch, state-controlled Russian media outlet RIA Novosti claimed the Kherson and Zaporizhzhia areas were officially being moved to Russian internet connections—days earlier, the outlet said the regions were also going to start using the Russian telephone code +7.

Zohora says that across occupied regions of Ukraine—including Kherson, Luhansk, Donetsk, and Zaporizhzhia—there is a patchwork of around 1,200 different ISPs. “We understand that most of them are forced to connect to Russian telecom infrastructure and reroute traffic,” Zohora tells WIRED. “Unfortunately, there are cases of massive routing of traffic of Ukrainian operators across Russian channels,” says Liliia Malon, the commissioner of Ukraine’s telecom regulator, the National Commission for the State Regulation of Electronic Communications. “Ukrainian networks are partially blocked or completely disconnected.”

Technical analysis confirms that the connections are switching. Internet monitoring company Cloudflare has observed KhersonTelecom’s traffic passing through Miranda Media for more than two weeks in June. Doug Madory, director of internet analysis at monitoring firm Kentik, has observed around half a dozen networks in Kherson connecting to the provider. “It's not a one-time thing,” Madory says. “Every couple of days, there's another company getting switched over to Russian transit from Ukraine.”

Since the start of Putin’s war in February, disrupting or disabling internet infrastructure has been a common tactic—controlling the flow of information is a powerful weapon. Russian missiles have destroyed TV towers, a cyberattack against a satellite system had knock-on impacts across Europe, and disinformation has tried to break Ukrainian spirits. Despite frequent internet blackouts, Ukraine’s rich ecosystem of internet companies has rallied to keep people online. While Ukrainian troops are successfully launching counterattacks against Russian occupation in the south of the country, Kherson remains controlled by invading forces. (In March, it became the first major city to fall into Russian hands, and its residents have lived under occupation for around 100 days, reporting numerous incidents of torture.)

“It's one thing to take over a city and to control the supply lines into the city, the flow of food or fuel,” says David Belson, head of data insight at Cloudflare, who has written about internet control in Kherson. But, he says, “controlling internet access and being able to manipulate the internet access into an occupied area” is a “new front” in the conflict.

There are multiple ways Russian forces are taking over internet systems. First, there is physical access—troops are seizing equipment. Spokespeople for two of Ukraine’s biggest internet providers, Kyivstar and Lifecell, say their equipment in Kherson was switched off by Russian occupying forces, and they don’t have any access to restore or repair equipment. (Throughout the war, internet engineers have been working amid shelling and attacks to repair damaged equipment). The SSSCIP says 20 percent of telecommunications infrastructure across the whole of Ukraine has been damaged or destroyed, and tens of thousands of kilometers of fiber networks are not functioning.

Once Russian forces have control of the equipment, they tell Ukrainian staff to reconfigure the networks to Miranda Media, Zohora says. “In case the local employees of these ISPs are not willing to help them with the reconfiguration, they are able to do it by themselves,” Zohora says. The SSSCIP, he adds, has advised staff not to risk their own lives or the lives of their families. “We hope that we are able to liberate these lands soon and this temporary period of blackmailing of these operators will pass off,” Zohora says, adding it is unlikely that communications in the region can be restored before the areas are liberated.

For the time being, at the very least, this means connections will be routed through Russia. When Gudz Dmitry Alexandrovich, the owner of KhersonTelecom, switched his connection to Miranda Media for the first time at the start of May, he claims some customers thanked him because he was getting people online, while others chastised him for connecting to the Russian service. “On May 30 again, like on April 30, everything absolutely everything fell and only Miranda's channels work,” Alexandrovich says in a translated online chat. In a long Facebook post published on the company’s page at the start of May, he claimed he wanted to help people and shared photos of crowds gathering outside KhersonTelecom’s office to connect to the Wi-Fi.

Russia is also trying to control mobile connections. In recent weeks, a mysterious new mobile company has popped up in Kherson. Images show blank SIM cards—totally white with no branding—being sold. Little is known about the SIM cards; however, the mobile network appears to use the Russian +7 prefix at the start of a number. Videos reportedly show crowds of citizens gathering to collect the SIM cards. “The Russian forces realize they're at a disadvantage if they keep using Ukrainian mobile networks,” says Cathal Mc Daid, the chief technology officer at mobile security company AdaptiveMobile. The company has seen two separatist mobile operators in Donetsk and Luhansk expanding the territory they are covering to newly occupied areas.

Who controls the internet matters. While most countries place only limited restrictions on the websites people can view, a handful of authoritarian nations—including China, North Korea, and Russia, severely limit what people can access.

Russia has a vast system of internet censorship and surveillance, which has been growing in recent years as the country tries to implement a sovereign internet project that cuts it off from the rest of the world. The country’s System for Operative Investigative Activities, or SORM, can be used to read people’s emails, intercept text messages, and surveil other communications.

“Russian networks are fully controlled by the Russian authorities,” Malon, the Ukrainian telecom regulator, says. The rerouting of the internet in occupied Ukrainian areas, Malon says, has the goal of spreading “Kremlin propaganda” and making people believe Ukrainian forces have abandoned them. “They are afraid that the news about the progress of the Ukrainian army will encourage resistance in the Kherson region and facilitate real activities,” Zohora says.

At the heart of the rerouting is Miranda Media, the operator in Crimea that appeared following the region’s annexation in 2014. Among “partners” listed on its website are the Russian security service known as the FSB and the Russian Ministry of Defense. The company did not respond to a request for comment.

In many ways, Crimea may act as an example of what happens next in newly occupied areas. “Only in 2017, Crimea was completely disconnected from Ukrainian traffic. And now, as far as I know, it's only Russian traffic there,” says Ksenia Ermoshina, an assistant research professor at the Center for Internet and Society and an affiliated researcher at the Citizen Lab. In January last year, Ermoshina and colleagues published research on how Russia has taken control of Crimea’s internet infrastructure.

After it annexed Crimea in 2014, Russian authorities created two new internet cables running along the Kerch Strait, where they connect with Russia. This process took three years to complete—something Ermoshina calls a “soft substitution model,” with connections transferring slowly over time. Since then, Russia has developed more advanced internet control systems. “The power of the Russian censorship machine changed in between \[2014 and 2022\],” Ermoshina says. “What I'm afraid of is the strength of Russian propaganda.”

It’s likely that rerouting the internet in Kherson and the surrounding areas is seen by Russian authorities as a key step in trying to legitimize the occupation, says Olena Lennon, a Ukrainian political science and national security adjunct professor at the University of New Haven. The moves could also be a blueprint for future conflicts.

Alongside internet rerouting in Kherson and other regions, Russian officials have started handing out Russian passports. Officials claim a Russian bank will soon open in Kherson. And the region has been moved to Moscow’s time zone by occupying forces. Many of the steps echo what previously happened in Crimea, Donetsk, and Luhansk. “Russia is making it clear that they're there for a long haul,” Lennon says, and controlling the internet is core to that. “They're making plans for a long-term occupation.”

Russia Is Taking Over Ukraine’s Internet

Nokia "G-2425G-A" Bharti Airtel Routers Hardware version "3FE48299DEAA" Software Version "3FE49362IJHK42" is vulnerable to Cross-Site Scripting (XSS) via the admin->Maintenance>Device Management.

**\# Exploit Title:** Nokia “G-2425G-A” Bharti Airtel Routers Hardware version “3FE48299DEAA” Software Version “3FE49362IJHK42” is vulnerable to Cross-Site Scripting (XSS) via admin->Maintenance>Device Management.

#Exploit Author: Shubham Pandey

#vendor: Nokia | Airtel

#Application Link: https://www.indiamart.com/proddetail/nokia-ont-g-2425g-a-gpon-ont-router-23710241448.html

#Hardware version “3FE48299DEAA” Software Version “3FE49362IJHK42”

**What is Stored XSS :**

XSS is Stand for Cross-Site Scripting. Stored XSS is a type of XSS. In Which an attacker permanently injects the malicious javascript into the database of the target server. A common impact of XSS is that the attacker can steal the cookies of users, deface the web application, and redirect the user’s to phishing pages.

Stored XSS is also known as Persistent XSS.

**Attack Vector:**

An attacker injects the XSS payload in Device Management in the place where the user can set Host Alias, Now each time user visits the application the XSS triggers, and the Attacker can redirect the user to some malicious or phishing webpages according to the crafted payload.

**Vulnerable Parameter:** “admin->Maintenance>Device Management.”

**Steps to Reproduce:**

1.  Go to Maintenance>Device Management
2.  Fill in the details and Put a payload on the “Host Alias=”

“>’><details/open/ontoggle=confirm(‘9560802349’)>

3\. Router Application Accept the payload and stored it permanently until someone deletes it intently.

Video POC

**Author: Shubham Pandey**

https://www.linkedin.com/in/shubham-pandey-10704014b

CVE-2022-30903: XSS Found In Nokia G-2425G-A Home WIFI Router - Shubham pandey - Medium

Researchers demonstrated a possible way to track individuals via Bluetooth signals.

Researchers demonstrated a possible way to track individuals via Bluetooth signals.

Researchers warn Bluetooth signals can be used to track device owners via a unique fingerprinting of the radio signal. The technique was presented via a paper presented at IEEE Security and Privacy conference last month by researchers at the University of California San Diego.

The paper suggests that minor manufacturing imperfections in hardware are unique with each device, and cause measurable distortions which can be used as a “fingerprint to track a specific device”.

“To perform a physical-layer fingerprinting attack, the attacker must be equipped with a Software Defined Radio sniffer: a radio receiver capable of recording raw IQ radio signals,” said researchers in a paper (PDF) titled “Evaluating Physical-Layer BLE Location Tracking Attacks on Mobile Devices.”

Gadgets such as smartwatches, fitness trackers, and smartphones transmit a signal called Bluetooth beacons with an average rate of 500 beacons per minute. These constantly transmitting signals enable the functionality for lost device tracking and COVID-19 tracing apps.

The critical insight from the researchers is that Bluetooth can also be used for tracking “in a highly accurate way”, as the previously known wireless fingerprints use to track Wi-Fi and other wireless technologies.

“This is important because in today’s world Bluetooth poses a more significant threat as it is a frequent and constant wireless signal emitted from all our personal mobile devices,” wrote co-author Nishant Bhaskar, a Ph.D. student at UC San Diego.

****How Tracking of Bluetooth Signals Works****

For Wi-Fi, the fingerprint techniques are based on the long string called “preamble”, Bluetooth beacon signals cannot be tracked in the same way because the preamble used is shorter in comparison to Wi-Fi signals.

“The short duration gives an inaccurate fingerprint, making prior techniques not useful for Bluetooth tracking,” wrote co-author Hadi Givehchian, a Ph.D. student at UC San Diego.

A new method was designed by the researcher that “doesn’t rely on the preamble” but focuses on the complete Bluetooth signal. The algorithm estimates two values. The two values are CFO (carrier frequency offset) and I/Q in the BLE signal. Researchers said that each varies according to the slight difference in the devices. Next, the imperfections for each packet are calculated by the Mahalanobis distance, and the results determined “how close the features of the new packet” is in comparison to previously recorded fingerprint.

“Researchers tested their method to track Bluetooth fingerprints on campus. They use an off-the-shelf device to track and identify devices.” – UC San Diego

Mahalanobis is a technical term described by Wikipedia as: “The Mahalanobis distance is a measure of the distance between a point P and a distribution D, introduced by P. C.”

Researchers continue, explaining; “The MAC address of every BLE device is stable for a limited duration of time, we can receive multiple packets that we know belong to the same BLE device,” the researcher said. The average of multiple packets can be used to increase identification accuracy.

The scientist evaluates the results through several real-world experiments. Initially, they found 40 percent discrete signals out of 162 devices in public. Another scaled-up experiment includes 647 devices “in a public hallway across two days” and found 47 percent unique fingerprints.

Factors such as changes in ambient temperature can alter the Bluetooth beacon, as well as the power ratio for different devices affects the distance up to which these devices can be tracked.

The researchers claim that despite these barriers, a large number of devices can be tracked and do not require sophisticated equipment, “the attack can be performed with equipment that costs less than $200.” the researcher noted.

**Solutions**

At the core level, Bluetooth hardware devices have to be redesigned, but the researcher working on an easier solution. The team planned to hide the Bluetooth fingerprints “via digital signal processing in the Bluetooth device firmware”

Additionally, the team is exploring the possibility that whether the inducing method can be implemented in other devices. “Every form of communication today is wireless, and at risk, we are working to build hardware-level defenses to potential attacks,” wrote co-author Dinesh Bharadia, a professor at the UC San Diego.

“Overall, we found that BLE does present a location tracking threat for mobile devices. However, an attackers ability to track a particular target is essentially a matter of luck,” the researcher concluded.

Bluetooth Signals Can Be Used to Track Smartphones, Say Researchers

A new research undertaken by a group of academics from the University of California San Diego has revealed for the first time that Bluetooth signals can be fingerprinted to track smartphones (and therefore, individuals).
The identification, at its core, hinges on imperfections in the Bluetooth chipset hardware introduced during the manufacturing process, resulting in a "unique physical-layer

A new research undertaken by a group of academics from the University of California San Diego has revealed for the first time that Bluetooth signals can be fingerprinted to track smartphones (and therefore, individuals).

The identification, at its core, hinges on imperfections in the Bluetooth chipset hardware introduced during the manufacturing process, resulting in a "unique physical-layer fingerprint."

"To perform a physical-layer fingerprinting attack, the attacker must be equipped with a Software Defined Radio sniffer: a radio receiver capable of recording raw IQ radio signals," the researchers said in a new paper titled "Evaluating Physical-Layer BLE Location Tracking Attacks on Mobile Devices."

The attack is made possible due to the ubiquitous nature of Bluetooth Low Energy (BLE) beacons that are continuously transmitted by modern devices to enable crucial functions such as contact tracing during public health emergencies.

The hardware defects, on the other hand, stem from the fact that both Wi-Fi and BLE components are often integrated together into a specialized "combo chip," effectively subjecting Bluetooth to the same set of metrics that can be used to uniquely fingerprint Wi-Fi devices: carrier frequency offset and IQ imbalance.

Fingerprinting and tracking a device then entails extracting CFO and I/Q imperfections for each packet by computing the Mahalanobis distance to determine "how close the features of the new packet" are to its previously recorded hardware imperfection fingerprint.

"Also, since BLE devices have temporarily stable identifiers in their packets \[i.e., MAC address\], we can identify a device based on the average over multiple packets, increasing identification accuracy," the researchers said.

That said, there are several challenges to pulling off such an attack in an adversarial setting, chief among them being that the ability to uniquely identify a device depends on the BLE chipset used as well as the chipsets of other devices that are in close physical proximity to the target.

Other critical factors that could affect the readings include device temperature, differences in BLE transmit power between iPhone and Android devices, and the quality of the sniffer radio used by the malicious actor to execute the fingerprinting attacks.

"By evaluating the practicality of this attack in the field, particularly in busy settings such as coffee shops, we found that certain devices have unique fingerprints, and therefore are particularly vulnerable to tracking attacks, others have common fingerprints, they will often be misidentified," the researchers concluded.

"BLE does present a location tracking threat for mobile devices. However an attacker's ability to track a particular target is essentially a matter of luck."

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

Researchers Find Bluetooth Signals Can be Fingerprinted to Track Smartphones

The company's vision for the future of cloud security is based on simplified, horizontal coverage across multiple cloud platforms.

Networking giant Cisco has unveiled a plan to simplify security operations, including the debut of an open security platform called Security Cloud, conceived as a unified platform for end-to-end security across hybrid multicloud environments.

The platform offers threat prevention, detection, response, and remediation capabilities, as well as less-intrusive methods for risk-based authentication, including a Wi-Fi fingerprint.

Cisco is also emphasizing intelligent user and device identity verification checks that run continuously and in the background.

**Horizontal Coverage**

TK Keanini, CTO of Cisco Secure, explains that in an age where organizations are protecting assets across multiple clouds — be they Microsoft Azure, Amazon AWS, or Google Cloud Platform — security teams are struggling to provide uniform, horizontal coverage across this infrastructure.

"We're trying to abstract away networking and security to a layer that is completely horizontal across that which you protect — your compute and storage," Keanini says. "Where before, networking and security were sometimes living in those silos, we're now logically above it. We want to provide a function that's consistent and has the economics of cloud."

Featuring Cisco Meraki SD-WAN technology, the secure access service edge (SASE) subscription service Cisco+ Secure Connect Now streamlines deployment and management of SASE through a cloud-managed platform with a unified dashboard.

A unified Secure Client is designed to help simplify the streaming of Cisco Secure agents, including AnyConnect, Secure Endpoint, and Umbrella.

"With Secure Connect, we tried to basically abstract away the complexity and hand you an application experience," Keanini says. "We're going after a person who doesn't ever want to be a networking expert, or they just want the network to work, and they want to control it via an app."

Cisco is also leveraging the OpenID Foundation's Shared Signals and Events standards, including CAEP and RISC, to build session trust analysis by sharing information between vendors.

The company also has enhanced its Secure Cloud Analytics, which automatically promotes alerts into SecureX and maps those alerts to MITRE ATT&CK.

It also debuted the Secure Firewall 3100 Series, which features an AI-powered encrypted visibility engine, uses machine learning (ML) technology to uncover threats, and offers a custom security research service, called Talos Intelligence On-Demand.

Keanini says that the through line with all of these services, as well as with Cisco's Security Cloud vision, is simplicity — specifically, providing services that remove complexity for organizations and individuals.

"You're good if you provide security, but you're even better if you provide security and usability," he says. "If you're going to reach the common person that just never wants to be a security expert, you got to deliver an application experience. That's really simple."

Cisco Revamps Cloud Security Strategy With New Secure Access, SASE Portfolio

After dragging their feet for months Owl Labs has released a patch for vulnerabilities that were publicly disclosed a week ago. The company denies the seriousness of the vulnerabilities.
The post Update now! Patch against vulnerabilities in Meeting Owl Pro and Whiteboard Owl devices appeared first on Malwarebytes Labs.

After a decent amount of pressure, Owl Labs has finally released updates for vulnerabilities in Meeting Owl, and Whiteboard Owl cameras. The vulnerabilities were reported to Owl Labs in January,

One of the vulnerabilities, CVE-2022-31460 has been added to the Known exploited vulnerabilities catalog by the Cybersecurity & Infrastructure Security Agency (CISA) and needs to be updated by June 22, 2022.

**Owl Labs**

Owl Labs makes 360-degree video conferencing equipment for classrooms and boardrooms. It produces several pieces of hardware, including the Meeting Owl Pro, a speaker fitted with cameras, microphones and an owl-like face, and a whiteboard camera for hybrid meetings.

**The research**

Researchers at modzero examined the Meeting Owl and found serious defects in the built-in security mechanisms.

And these vulnerabilities were not minor. By exploiting the vulnerabilities an attacker could find registered devices, their data, and owners from around the world. Attackers could also access confidential screenshots of whiteboards or use the Owl to get access to the owner’s network.

The researchers found the existence of at least four different ways to bypass the PIN protection (passcode), which protects the Owl from unauthorized use.

**The vulnerabilities**

The Common Vulnerabilities and Exposures (CVE) database is a list of publicly disclosed computer security flaws. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). Below you will find the CVEs assigned to the vulnerabilities:

*   CVE-2022-31460: Owl Labs Meeting Owl 5.2.0.15 allows attackers to activate Tethering Mode with hard-coded credentials. The tethering mode turns the Owl into an access point (AP) by creating a new Wi-Fi network while staying connected to the existing Wi-Fi. This basically allows any authorized user to turn the Owl into a rogue access point. A rogue access point by definition constitutes a wireless access point installed on a secure network without explicit authorization from a local network administrator. Hard-coded credentials is where embedded authentication data, like user IDs and passwords, are included the source code of the device.

**Passcode bypasses**

*   CVE-2022-31463: Owl Labs Meeting Owl 5.2.0.15 does not require a password for Bluetooth commands, because only client-side authentication is used. To extend the range of devices and provide remote control by default Owl Labs uses the Bluetooth functionality. The vulnerability makes it possible for an attacker in proximity to control the devices to the extent that they can disable any set passcode.
*   CVE-2022-31462: Owl Labs Meeting Owl 5.2.0.15 allows attackers to control the device via a backdoor password which can be found in Bluetooth broadcast data. A hardcoded backdoor passcode exists which depends on the serial number of the device. This hardcoded passcode is the SHA-1 hash representation of the devices’ software serial number. The hash is broadcasted as the name of the Owl over Bluetooth Low Energy (BLE). So an attacker in close proximity can simply get hold of the hardcoded backdoor passcode. Also, it is possible to generate all existing serial numbers by a script.
*   CVE-2022-31461: Owl Labs Meeting Owl 5.2.0.15 allows attackers to deactivate the passcode protection mechanism via a certain message from the companion app. An attacker would have to be close enough to the Owl to communicate over BLE to exploit this vulnerability.
*   CVE-2022-31459: Owl Labs Meeting Owl 5.2.0.15 allows attackers to retrieve the SHA1 hash of the passcode over BLE. It is possible to brute-force the passcode from the hash in seconds since it consist only of digits. An attacker with knowledge of the BLE endpoint can use this knowledge to control any Meeting Owl in their proximity.

**What is Bluetooth Low Energy (BLE)?**

BLE is a Bluetooth protocol which launched in 2010, especially designed to achieve low power consumption and latency, while at the same time accommodating the widest possible interoperable range of devices. The BLE protocol also does not require paring between the sender and receiver and it can send authenticated unencrypted data.

For those interested, a full disclosure report by modzero is available online.

**Slow pokes**

Another worrying factor in the report is the timeline of disclosure which gives the impression of an uninterested attitude and unwillingness to fix on the part of Owl Labs. Given the seriousness of the vulnerabilities and the nature of Owl Labs’ clients one might have wished it was treated with more urgency.

The researchers shifted the time of disclosure several times until they were finally fed up with the unresponsiveness of Owl Labs. And only after the vulnerabilities had been disclosed Owl Labs came up with patches for the vulnerabilities. On June 6, 2022, Owl Labs stated that all high-security issues had been addressed, and said it was in the process of implementing a few additional updates. Earlier Owl Labs said that the likelihood that its customers were affected by these issues is low.

**Mitigation**

Meeting Owl Pro and Whiteboard Owl will automatically send over the air software updates to Owls that are connected to Wi-Fi and plugged into power over night.

To determine what version of software is on your Owl, follow these steps.

If your Owl’s software is out of date, please follow these instructions for how to update your Owl’s software.

We are pretty sure this owl will have a tail and will keep you updated about any developments here.

Update now! Patch against vulnerabilities in Meeting Owl Pro and Whiteboard Owl devices

Fedora 36 and Red Hat Enterprise Linux 9 (RHEL 9) are out, and both ship with OpenSSL 3 that has tighter security defaults and a brand new "provider" architecture.

Fedora 36 and Red Hat Enterprise Linux 9 (RHEL 9) are out, and both ship with OpenSSL 3 that has tighter security defaults and a brand new "provider" architecture. While users were testing the beta and other development versions, issues in interoperability with servers and devices such as Wi-Fi access points showed up and caused some confusion between various uses of the rather overloaded word "legacy" that we would like to clear up.

**LEGACY cryptographic policy**

Fedora and RHEL provide system-wide configurations that apply to all cryptographic libraries in the crypto-policies package since RHEL 8. This provides more consistency for cryptography across all applications.

There are various policies that system administrators can enable using update-crypto-policies --set POLICYNAME from the crypto-policies-scripts package. One of those is the first encounter with the "legacy" keyword: the LEGACY cryptographic policy generates configuration files for GnuTLS, OpenSSL, NSS, BIND, libkrb5, OpenSSH, OpenJDK and libssh that maximize compatibility with older systems while still providing a minimum level of security over the lifetime of the operating system.

The lifetime of the operating system also explains why the LEGACY crypto-policy on Fedora has lower requirements than its RHEL 9 counterpart. Fedora 36’s lifetime is much shorter than that of RHEL 9, so the configuration shipped with RHEL must hold up longer (and thus be tighter). For example, the Fedora 36 LEGACY cryptographic policy includes support for TLS 1.0, while RHEL 9 requires TLS 1.2 at minimum.

Other notable preconfigured cryptographic policies are DEFAULT and FUTURE. Additionally, the crypto-policies system supports subpolicies that allow enabling or disabling specific features, for example using update-crypto-policies --set DEFAULT:SHA1 to use the default policy, but with support for signatures using the SHA-1 digest. See the crypto-policies(7) manpage, the Red Hat Customer Portal, and previous coverage of crypto-policies in this blog for more details, including information on how to define your own policies and subpolicies.

**The OpenSSL legacy provider**

Fedora 36 and RHEL 9 both ship OpenSSL 3 for the first time, and the OpenSSL developers introduced a concept called "providers" in this version. Providers contain implementations of cryptographic primitives grouped by specific properties. For example, the OpenSSL FIPS provider contains implementations that are undergoing validation according to NIST’s Cryptographic Module Validation Program.

This is where we meet the second instance of "legacy" we’re covering today: the OpenSSL legacy provider. The OpenSSL developers have decided to move a number of outdated algorithms into this provider which isn’t loaded by default and must be enabled explicitly — either through configuration or programmatically — if applications need to use any of these algorithms.

The choices made by the OpenSSL team on which algorithms are "legacy" are rather conservative: the RIPEMD-160 hash function, the RC4, RC5, and single DES encryption algorithms as well as the PBKDF1 key derivation function are the most prominent algorithms that are no longer available by default in OpenSSL.

Applications that still require those deprecated algorithms for special purposes usually load the legacy provider on demand where needed. As a consequence, system administrators should rarely, if ever, have to enable the OpenSSL legacy provider manually. In FIPS mode, these algorithms will be unavailable.

**Unsafe legacy renegotiation in TLS**

Our final stop on today’s journey across the land of word "legacy" brings us to Transport Layer Security or TLS, also often known by its predecessor’s name, SSL. Starting with OpenSSL 3, and thus Fedora 36 and RHEL 9, TLS connections expect the server to send the renegotiation\_info extension, specified in 2010 in RFC5746 in response to CVE-2009-3555. Unfortunately, it seems some servers out there still do not yet support this extension, which causes connections to fail with a rather cryptic message that contains our keyword:

SSL\_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled

In particular, older enterprise Wi-Fi hardware seems to have some catching up to do with the relevant standards. You can follow the discussion and witness the term confusion for Fedora 36 in bug 2072070, and for RHEL 9 in bug 2077973.

**Conclusion**

"Legacy" has many uses in cryptography, and this post can only cover a small subset. Nonetheless, we hope that our discussion of these three uses helps you distinguish these cases and draw the right conclusions. If you would like to learn more about the security capabilities within RHEL, the Red Hat Product Security Center is a great place to get started.

Tag

#wifi