Dell faces its third data leak in a week as hacker “grep” continues targeting the tech giant. Sensitive…

Dell faces its third data leak in a week as hacker “grep” continues targeting the tech giant. Sensitive internal files, including project documents and MFA data, were exposed. Dell has yet to issue a formal response.

Dell has allegedly been hit with yet another data leak, marking the third such incident in a week. The threat actor, who goes by the alias “grep,” has claimed responsibility for the latest breach and continues to target the tech giant.

This time, the hacker has leaked approximately 500 MB of sensitive data, including internal documents, PDFs, images, internal device testing videos, and Multi-Factor Authentication (MFA) data, which if confirmed by Dell could further escalate concerns over the company’s data security.

According to information obtained by Hackread.com, the hacker shared details of the data leak, stating that Dell suffered a third breach that exposed internal files. The hacker revealed, “I knew Dell would fix their failure without confirming or denying my claims, for the same reason I had exfiltrated more data when I breached the internal employees, which was not leaked and waited for this exact moment.”

The leaked data includes access vectors and references to Chinese infrastructure, which, if not at a large scale, could still have some impact on the company’s operations.

The hacker on the breach forum boosted about the data leak and the leaked data was analysed by Hackread.com (Screenshot: Hackread.com)

**Leaked Data Includes Internal Tickets and Infrastructure Documents**

Among the leaked data is a CVS file titled “Ticket Summary – FY23,” which includes details of Dell’s internal ticketing system. Some of the entries shared in the leak include:

*   Incident reports on Agile access, VPN issues, proxy requirements for testing, and application migrations.
*   Ticket summaries that highlight VPN enhancements, DevOps software access requests, and network setups.

Additionally, the hacker shared a range of files and folders containing critical infrastructure information, such as:

*   “China Infra Compute.pdf”
*   “Global Project FY23.pdf” and “Global Project FY25.pdf”
*   “MFA Authentication – Cisco DUO.pdf”
*   Various project summaries and security-related documents.

The documents released by “grep” provide a snapshot of Dell’s internal operations and project infrastructure, revealing sensitive information that could pose security risks if exploited. Therefore, for security reasons; we are withholding specific details of the leaked files.

> 🚨Data Breach Update: Threat Actor Claims Third Breach of DELL
> 
> "Greg" is now claiming that DELL suffered a third data breach, this time compromising data such as "PDFs, images, videos, models, MFA data, along with their access vectors, including Chinese infrastructure."
> 
> In the… https://t.co/lTaOeC0IAL pic.twitter.com/8w3Fh9flo8
> 
> — HackManac (@H4ckManac) September 25, 2024

**Pattern of Breaches: A Coordinated Attack or Piecemeal Leaks?**

This third leak follows two previous data breaches conducted by the same hacker within a short time frame. **On September 19, 2024**, “grep” leaked data belonging to over 12,000 Dell employees, sparking an internal investigation. Just days later, **on September 22**, more sensitive internal files were released, allegedly compromised through Dell’s use of Atlassian tools.

In today’s data leak, the hacker clarified that all the data was stolen during a single breach, but he is strategically leaking it in parts. This statement eliminates speculation that Dell is facing repeated attacks, confirming instead that the data is being gradually released from one initial breach.

It is worth noting that Dell has yet to confirm the extent of the damage or whether the hacker gained access through a third-party vendor, as seen in other recent incidents. The hacker’s method aligns with his earlier attack, where he **leaked 12,000 Twilio records** from a compromised customer. Twilio confirmed to Hackread.com that it was a third-party breach, which resulted in the leak of only one Twilio customer’s data.

**Dell’s Response and Next Steps**

So far, Dell has not released a formal statement regarding today’s data leak. With three data leaks in just one week, concerns about Dell’s cybersecurity are growing. Hackread.com has reached out to Dell for comment, and this article will be updated as more information becomes available. Stay tuned!

1.  **Hacker Leaks Data of 33,000 Accenture Employees**
2.  **Acer Online Store Hacked; 34,000 Customers’ Data Stolen**
3.  **Hacker Leaks Thousands of Microsoft and Nokia Employee Data**
4.  **Shadow IT: Personal GitHub Repos Expose Employee Cloud Secrets**
5.  **Nissan Confirms Data Breach Affected 100K Customers, Employees**

Dell Hit by Third Data Leak in a Week Amid “grep” Cyberattacks

Another day, another claim of Dell data breach!

Hackers claim a second Dell data breach within a week, exposing sensitive internal files via compromised Atlassian tools. Allegedly, data from Jira, Jenkins, and Confluence was leaked. Dell is already investigating the first incident.

On September 19, 2024, _Hackread.com_ **published an exclusive report** detailing claims of a Dell data breach involving sensitive information related to 10,863 Dell employees. The same hacker behind the original breach is now claiming that Dell has been “breached again,” suggesting a larger ongoing issue.

The hacker, who operates under the alias “grep” on the infamous cybercrime platform Breach Forums, posted these claims on Sunday, September 22, 2024. In this post, “grep” revealed that Dell has suffered another significant breach, this time with the help of a fellow hacker known as “Chucky.” Together, they allegedly compromised Dell’s internal systems, exposing confidential data.

According to “grep,” the breach contains data related to Jira files, database tables, and schema migrations, amounting to a total of 3.5 GB of uncompressed data. The hackers claim to have gained access by compromising Dell’s Atlassian software suite, including Jenkins and Confluence, widely used tools for software development and collaboration.

Here’s the exact message shared by the hacker on the forum:

_Compromised data: Jira’s files, DB tables, schema migration, etc., totalling_ 3.5GB uncompressed. This time, it was breached by Chucky. Before Dell makes any claims, we both compromised your Atlassian and accessed Jenkins, Confluence, etc.  
GDPR said time is ticking, by the way, _xD._

The hacker on Breach Forum announcing his leak (Screenshot credit: Hackread.com)

In response to the first alleged breach, Dell told _Hackread.com_ that it was aware of the situation and had launched an investigation. However, as of now, the company has not addressed the latest breach claims.

The _Hackread.com_ research team has analyzed some of the files and determined that they likely contain sensitive information about Dell’s internal infrastructure. This includes system configurations, user credentials, security vulnerabilities, and development processes. If confirmed, this information could potentially be leveraged to target Dell’s systems on a much larger scale.

Further review of the leaked files suggests that they belong to a variety of enterprise tools and environments used by Dell, including Jira, database tables, schemas, and Atlassian tools such as Jenkins and Confluence. For security reasons, we are withholding specific details of the compromised files.

Screenshot from the leaked data Screenshot credit: Hackread.com)

_Hackread.com_ has reached out to Dell for a comment and will update this article as the story develops.

1.  **Hacker Leaks Data of 33,000 Accenture Employees**
2.  **Acer Online Store Hacked; 34,000 Customers’ Data Stolen**
3.  **Hacker Leaks Thousands of Microsoft and Nokia Employee Data**
4.  **Shadow IT: Personal GitHub Repos Expose Employee Cloud Secrets**
5.  **Nissan Confirms Data Breach Affected 100K Customers, Employees**

Hackers Claim Second Dell Data Breach in One Week

A hacker claims Dell suffered a “minor” breach, exposing over 10,000 employee records. The incident raises cybersecurity concerns…

A hacker claims Dell suffered a “minor” breach, exposing over 10,000 employee records. The incident raises cybersecurity concerns amid ongoing threats targeting businesses by tricking employees into phishing and phone call scams.

A hacker using the alias “grep” claims that the technology giant Dell has experienced a “minor” data breach, resulting in the theft of over ten thousand (10,863) employee records.

This information was revealed by the hacker on the notorious hacker and cybercrime platform Breach Forums, where the allegedly stolen data was leaked earlier today, September 19, 2024. The hacker also claims that the breach occurred earlier this month.

The hacker on Breach Forums (Screenshot: Hackread.com)

The Hackread.com research team managed to analyze the data, which revealed the leak contained the following information:

*   **Full names**
*   **Employee** **ID**: A unique identifier for the employee.
*   **Employee Active Status**: Indicates whether the employee is currently active
*   **Employee DNO**: This may represent a department number or another internal identifier.
*   **Internal Employee ID**: A unique internal identifier that seems to be a hashed or encoded value.

There are only two email addresses associated with the @Dell.com domain. However, the good news is that there are no plain text passwords or other personally identifiable information (PII) included.

Screenshot from the leaked data (Credit: Hackread.com)

The bad news is that the leaked information still presents a major cybersecurity threat to Dell. Here’s how:

Recently, cybercriminals and state-backed hackers have been targeting businesses and organizations **through their employees**. A notable attack was uncovered by cybersecurity firm GuidePoint, which affected over 130 U.S. organizations across various industries. **The campaign** employed social engineering tactics, with threat actors posing as IT support staff to call employees and trick them into revealing their VPN credentials.

Dell’s alleged “minor” breach could provide threat actors with additional details about the company’s employees, making them more susceptible to phishing attempts or phone scams, as mentioned above.

****Wouldn’t be the first time for Dell****

This is not the first time Dell has made headlines for cybersecurity-related issues. In May 2024, the Round Rock, Texas-based company **disclosed a data breach** after another hacker on a breach forum attempted to sell 49 million alleged customer records.

Although the company did not disclose the exact number of affected customers at that time, the compromised data included full names, physical addresses, Dell hardware and order information, including service tags, item descriptions, order dates, and related warranty information.

Hackread.com has reached out to Dell, and this article will be updated accordingly if the company responds. Stay tuned!

1.  **Hacker Leaks Data of 33,000 Accenture Employees**
2.  **Acer Online Store Hacked; 34,000 Customers’ Data Stolen**
3.  **Hacker Leaks Thousands of Microsoft and Nokia Employee Data**
4.  **Shadow IT: Personal GitHub Repos Expose Employee Cloud Secrets**
5.  **Nissan Confirms Data Breach Affected 100K Customers, Employees**

Hacker Claims “Minor” Data Breach at DELL; Leaks Over 10,000 Employee Details

One of Silicon Valley’s most influential lobbying arms joins privacy reformers in a fight against the Biden administration–backed expansion of a major US surveillance program.

A trade organization representing some of the world’s largest information technology companies—Google, Amazon, IBM, and Microsoft among them—say its members are voicing strong opposition to ongoing efforts by the Biden administration to dramatically expand a key US government surveillance authority.

The US Senate is poised to vote Thursday on legislation that would extend a global wiretap program authorized under the Foreign Intelligence Surveillance Act (FISA). Passed by the House of Representatives last week, a provision contained in the bill—known as the Reforming Intelligence and Securing America Act (RISAA)—threatens to significantly expand the scope of the spy program, helping the government to compel the assistance of whole new categories of businesses.

Legal experts argue the provision could enable the government to conscript virtually anyone with access to facilities or equipment housing communications data, forcing “delivery personnel, cleaning contractors, and utilities providers,” among others, to assist US spies in acquiring access to Americans’ emails, phone calls, and text messages—so long as one side of the communication is foreign.

A global tech trade association, the Information Technology Industry Council (ITI), is now urging Congress not to pass RISAA without removing a key provision “dramatically expanding the scope of entities and individuals covered” by the program, known as Section 702. Changes to the 702 program included in the House bill, ITI says, would only serve to send customers in the US and abroad fleeing to foreign competitors, convincing many that technology in the US is far too exposed to government surveillance.

The group’s membership includes several major equipment manufacturers, such as Ericsson, Nokia, and Broadcom, as well as large cloud storage providers like Google, Microsoft, IBM, and Salesforce. “ITI’s position is that the provision should be removed,” the group’s communications director, Janae Washington, tells WIRED. “Our positions are based on member consensus.”

The individual ITI member companies WIRED contacted for their comment on the legislation did not immediately respond or declined to comment.

The provision under fire stems from a ruling handed down by the US government’s secret surveillance court—the FISA court—that oversees the 702 program. The program is designed to target the communications of foreigners, including calls and emails to and from US citizens. To this aim, the federal statute specifies that the government may compel the assistance of businesses that fall into the category of what it calls “electronic communications service providers,” or ECSPs.

Companies like Google and AT&T have typically fallen into this category as direct providers of the services being wiretapped; however, the US government has also moved in recent years to interpret the term more broadly as part of an effort to expand the roster of entities whose assistance it’s allowed to compel.

The FISA court, in a decision backed by its own review body, pushed back against the expanded definition, telling the government that what constitutes an ECSP remains “open to reconsideration by the branches of government whose competence and constitutional authority extend to statutory revision.”

More concisely: The court reminded the government that only Congress has the power to rewrite the law.

The US Intelligence Community (IC) thus began a campaign to ensure that this year’s legislation reauthorizing the 702 program redefines “ECSP” to address what it calls a “collection gap resulting from recent court opinions.”

Internal emails obtained by WIRED show that members of the House Intelligence Committee served as intermediaries for the IC in its campaign to convince Congress to support the provision. An email circulated to House members in February by Michael Calcagni, the intel committee’s deputy staff director, for instance, informed lawmakers that the “collection gap” was both “serious and dangerous” and that “contrary to unsubstantiated assertions, it would not authorize or enable the Government to conduct surveillance of any American who connects to public WiFi at a Starbucks or McDonalds.”

One of the nation’s leading FISA experts, Marc Zwillinger, a private attorney who has twice appeared before the FISA Court of Review, began raising the alarm in December over the provision, pointing to text that would allow the government to compel the assistance of “any service provider” with access to “equipment that is being or may be used to transmit or store” communications, so long as one of the recipients is a foreigner reasonably believed to be overseas.

While rejecting Zwillinger’s analysis publicly, House intel members nevertheless attempted to quietly “narrow” the provision to clamp down on any criticism, excluding a handful of business types such as senior centers, hotels, and coffee shops. In a follow-up last week, Zwillinger and other attorneys who’ve made rare appearances before the FISA court characterized the intel committee’s improvements as “marginal,” saying the need for the exclusions only served to demonstrate the government is overreaching.

The provision, Zwillinger says, continues to ensnare owners and operators of facilities housing equipment used to store and carry data, “such as data centers and buildings owned by commercial landlords, who merely have access to communications equipment in their physical space.” The text could be interpreted to extend to “delivery personnel, cleaning contractors, and utility providers.” And while the new provision excludes businesses like coffee shops, those businesses typically rely on cloud computer services whose equipment remains subject to the 702 program’s expanded scope.

“Although the effects of this provision may be unintentional, its impacts would be very real,” ITI’s senior vice president of policy, John Miller, says. “The language in the provision vastly expands the US government’s warrantless surveillance capabilities, damaging the competitiveness of US technology companies large and small, and arguably imperiling the continued global free flow of data between the US and its allies.”

Should it become apparent to the world that America’s top IT companies—data centers, cloud providers, and security services alike—have been turned into a watering hole for the US Intelligence Community, many customers will “likely look to foreign competitors,” Miller says, companies whose technologies are viewed as less exposed to clandestine government requests.

“There is no greater responsibility of the US government than to provide for the security of the country,” he says, adding it was incumbent upon to craft legislation to address national security concerns “in a focused way.”

_Updated 4/17/2024, 6:30 pm ET: Added additional details clarifying ITI's position on RISAA._

Big Tech Says Spy Bill Turns Its Workers Into Informants

Nokia BMC Log Scanner version 13 suffers from a remote command injection vulnerability.

    # Exploit Title: Nokia BMC Log Scanner Remote Code Execution# Google Dork: N/A# Date: November 29, 2023# Exploit Author: Carlos Andres Gonzalez, Matthew Gregory# Vendor Homepage: https://www.nokia.com/# Software Link: N/A# Version: 13# Tested on: Linux# CVE : CVE-2022-45899DescriptionThe BMC Log Scanner web application, available on several hosts, is vulnerable to command injectionattacks, allowing for unauthenticated remote code execution. This vulnerability is especially significantbecause this service runs as root.Steps to Reproduce:In the Search Pattern field, type:;";commandReplacing the word "command" above with any Linux command.Root access can be confirmed with the id command or any other command that would requireroot access, such as displaying the contents of the /etc/shadow file."This issue was fixed in version 13.1.

Nokia BMC Log Scanner 13 Command Injection

By Waqas
Anonymous Sudan alleges that the cyber attack they conducted has crippled the reservation system and other online assets of the targeted entity.
This is a post from HackRead.com Read the original post: Anonymous Sudan Claims DDOS Attacks on UAE’s Flydubai Airline

Anonymous Sudan claims responsibility for the cyber attack, citing their belief that the UAE is providing support to the Rapid Support Forces (RSF) in Sudan as their motive.

Anonymous Sudan, the pro-Palestinian and Russian hacktivist group, has taken credit for a series of Distributed Denial of Service Attacks (DDoS attacks) on Flydubai, an Emirati government-owned airline in Dubai, United Arab Emirates.

The group’s latest claim closely follows their January 16th, 2024 announcement of targeting Thuraya Mobile Satellite Communications Company, an international mobile-satellite service (MSS) provider based in Dubai, United Arab Emirates (UAE).

It is worth noting that in both cyber attacks, the motives revealed by Anonymous Sudan were the UAE’s apparent support to the Rapid Support Forces (RSF) for communication. Notably, RSF is a paramilitary force formerly operated by the Government of Sudan, accused by the hacktivists of committing war crimes against the Sudanese people.

The alleged cyber attack was announced on February 1, 2024, by the group through its official Telegram channel. Anonymous Sudan typically announces its attacks via Telegram, with no known website utilized by the group thus far.

> _“We have conducted a significant cyber attack on the digital infrastructure of FlyDubai. We have hit the most critical parts of FlyDubai’s digital infrastructure in one. We have confirmed that the network of Flydubai is completely disrupted. Attacks against the UAE will continue as they continue to support the genocidal Rapid Support Forces in Sudan. We therefore claim any damage to the overall health of FlyDubai systems and any collateral damage.”_
> 
> Anonymous Sudan

Despite Flydubai’s official website remaining online, Anonymous Sudan claimed in a subsequent message a few hours later that Flydubai’s infrastructure, including the reservation system, had been severely affected, leaving the airline’s website as the only functional asset.

However, Hackread.com’s attempt to book a ticket on Flydubai’s website proved successful. Here’s what Anonymous Sudan had to say on Telegram:

Anonymous Sudan on Telegram (Screenshot: Hackread.com)

Hackread.com has reached out to Flydubai for a comment, and should the company respond, we will update this article accordingly. Nevertheless, DDoS attacks have emerged as a significant concern for businesses of all scales. According to Kaspersky’s report, the DDoS economy is flourishing on the dark web, with an increasing number of cybercriminals setting their sights on critical infrastructure.

While there are DDoS attack-mitigating companies out there, the first line of defence is to secure your IoT devices from becoming a zombie for botnets utilized in such attacks. Therefore, whether you are an unsuspecting user at home or administering a large corporation, make sure your cybersecurity defences are as strong as possible.

****RELATED ARTICLES****

1.  **ChatGPT Down? OpenAI Blames Outages on DDoS Attacks**
2.  **Google, Cloudflare, and AWS Disclose Largest DDoS Attack**
3.  **Popular Swing VPN Android App Turned Out to be DDoS Botnet**
4.  **DDoS Attacks Soar by 168% on Govt Services, StormWall Warns**
5.  **IoT Botnet DDoS Attacks Threaten Global Telecom Sector, Nokia**

Anonymous Sudan Claims DDOS Attacks on UAE’s Flydubai Airline

A collection of security flaws in the firmware implementation of 5G mobile network modems from major chipset vendors such as MediaTek and Qualcomm impact USB and IoT modems as well as hundreds of smartphone models running Android and iOS.
Of the 14 flaws – collectively called 5Ghoul (a combination of "5G" and "Ghoul") – 10 affect 5G modems from the two companies, out of which three

Vulnerability / Mobile Network

A collection of security flaws in the firmware implementation of 5G mobile network modems from major chipset vendors such as MediaTek and Qualcomm impact USB and IoT modems as well as hundreds of smartphone models running Android and iOS.

Of the 14 flaws – collectively called **5Ghoul** (a combination of "5G" and "Ghoul") – 10 affect 5G modems from the two companies, out of which three have been classified as high-severity vulnerabilities.

"5Ghoul vulnerabilities may be exploited to continuously launch attacks to drop the connections, freeze the connection that involve manual reboot or downgrade the 5G connectivity to 4G," the researchers said in a study published today.

As many as 714 smartphones from 24 brands are impacted, including those from Vivo, Xiaomi, OPPO, Samsung, Honor, Motorola, realme, OnePlus, Huawei, ZTE, Asus, Sony, Meizu, Nokia, Apple, and Google.

UPCOMING WEBINAR

Cracking the Code: Learn How Cyber Attackers Exploit Human Psychology

Ever wondered why social engineering is so effective? Dive deep into the psychology of cyber attackers in our upcoming webinar.

Join Now

The vulnerabilities were disclosed by a team of researchers from the ASSET (Automated Systems SEcuriTy) Research Group at the Singapore University of Technology and Design (SUTD), who also previously disclosed BrakTooth in September 2021 and SweynTooth in February 2020.

The attacks, in a nutshell, attempt to deceive a smartphone or a 5G-enabled device to connect a rogue base station (gNB), resulting in unintended consequences.

"The attacker does not need to be aware of any secret information of the target UE e.g., UE's SIM card details, to complete the NAS network registration," the researchers explained. "The attacker only needs to impersonate the legitimate gNB using the known Cell Tower connection parameters."

A threat actor can accomplish this by using apps like Cellular-Pro to determine the Relative Signal Strength Indicator (RSSI) readings and trick the user equipment to connect to the adversarial station (i.e., a software-defined radio) as well as an inexpensive mini PC.

Notable among the 14 flaws is CVE-2023-33042, which can permit an attacker within radio range to trigger a 5G connectivity downgrade or a denial-of-service (DoS) within Qualcomm's X55/X60 modem firmware by sending malformed Radio Resource Control (RRC) frame to the target 5G device from a nearby malicious gNB.

Successful exploitation of the other DoS vulnerabilities could require a manual reboot of the device to restore 5G connectivity.

Patches have been released by both MediaTek and Qualcomm for 12 of the 14 flaws. Details of the two other vulnerabilities have been withheld due to confidentiality reasons and are expected to be disclosed in the future.

"Finding issues in the implementation of the 5G modem vendor heavily impacts product vendors downstream," the researchers said, adding that "it can often take six or more months for 5G security patches to finally reach the end-user via an OTA update."

"This is because the software dependency of product vendors on the Modem / Chipset Vendor adds complexity and hence delays to the process of producing and distributing patches to the end-user."

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

New 5G Modems Flaws Affect iOS Devices and Android Models from Major Brands

In parse_gap_data of utils.cc, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with User execution privileges needed. User interaction is not needed for exploitation.

_Published December 4, 2023_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2023-12-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 (proximal/adjacent) code execution with no additional execution privileges needed. User interaction is not needed for exploitation. 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.

**2023-12-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-12-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 remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-40077

A-298057702

EoP

Critical

11, 12, 12L, 13, 14

CVE-2023-40076

A-303835719

ID

Critical

14

CVE-2023-40079

A-278722815

EoP

High

14

CVE-2023-40089

A-294228721

EoP

High

14

CVE-2023-40091

A-283699145

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40094

A-288896339

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40095

A-273729172

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40096

A-268724205

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40103

A-197260547

EoP

High

14

CVE-2023-45774

A-288113797

EoP

High

11, 12, 12L, 13, 14

CVE-2023-45777

A-299930871

EoP

High

13, 14

CVE-2023-21267

A-218495634

ID

High

11, 12, 12L, 13, 14

CVE-2023-40073

A-287640400

ID

High

11, 12, 12L, 13, 14

CVE-2023-40081

A-284297452

ID

High

11, 12, 12L, 13, 14

CVE-2023-40092

A-288110451

ID

High

11, 12, 12L, 13, 14

CVE-2023-40074

A-247513680

DoS

High

11, 12, 12L, 13

CVE-2023-40075

A-281061287

DoS

High

11, 12, 12L, 13, 14

**System**

The most severe vulnerability in this section could lead to remote (proximal/adjacent) code execution with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-40088

A-291500341

RCE

Critical

11, 12, 12L, 13, 14

CVE-2023-40078

A-275626001

EoP

High

14

CVE-2023-40080

A-275057843

EoP

High

13, 14

CVE-2023-40082

A-290909089

EoP

High

14

CVE-2023-40084

A-272382770

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40087

A-275895309

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40090

A-274478807

EoP

High

11, 12, 12L, 13, 14

CVE-2023-40097

A-295334906

EoP

High

11, 12, 12L, 13

CVE-2023-45773

A-275057847

EoP

High

13, 14

CVE-2023-45775

A-275340684

EoP

High

14

CVE-2023-45776

A-282234870

EoP

High

14

CVE-2023-21394

A-296915211

ID

High

11, 12, 12L, 13

CVE-2023-35668

A-283962802

ID

High

11, 12, 12L, 13

CVE-2023-40083

A-277590580

ID

High

12, 12L, 13, 14

CVE-2023-40098

A-288896269

ID

High

12, 12L, 13, 14

CVE-2023-45781

A-275553827

ID

High

12, 12L, 13, 14

**Google Play system updates**

There are no security issues addressed in Google Play system updates (Project Mainline) this month.

**2023-12-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-12-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.

**System**

The vulnerability in this section could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-45866

A-294854926

EoP

Critical

11, 12, 12L, 13, 14

**Arm components**

These vulnerabilities affect Arm components and further details are available directly from Arm. The severity assessment of these issues is provided directly by Arm.

   

CVE

References

Severity

Subcomponent

CVE-2023-3889  

A-295942985 \*

High

Mali

CVE-2023-4272  

A-296910715 \*

High

Mali

CVE-2023-32804  

A-272772567 \*

High

Mali

**Imagination Technologies**

These vulnerabilities affect Imagination Technologies components and further details are available directly from Imagination Technologies. The severity assessment of these issues is provided directly by Imagination Technologies.

   

CVE

References

Severity

Subcomponent

CVE-2023-21162  

A-292004168 \*

High

PowerVR-GPU

CVE-2023-21163  

A-292003338 \*

High

PowerVR-GPU

CVE-2023-21164  

A-292002918 \*

High

PowerVR-GPU

CVE-2023-21166  

A-292002163 \*

High

PowerVR-GPU

CVE-2023-21215  

A-291982610 \*

High

PowerVR-GPU

CVE-2023-21216  

A-291999952 \*

High

PowerVR-GPU

CVE-2023-21217  

A-292087506 \*

High

PowerVR-GPU

CVE-2023-21218  

A-292000190 \*

High

PowerVR-GPU

CVE-2023-21228  

A-291999439 \*

High

PowerVR-GPU

CVE-2023-21263  

A-305095406 \*

High

PowerVR-GPU

CVE-2023-21401  

A-305091236 \*

High

PowerVR-GPU

CVE-2023-21402  

A-305093885 \*

High

PowerVR-GPU

CVE-2023-21403  

A-305096969 \*

High

PowerVR-GPU

CVE-2023-35690  

A-305095935 \*

High

PowerVR-GPU

CVE-2023-21227  

A-291998937 \*

High

PowerVR-GPU

**MediaTek components**

These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

   

CVE

References

Severity

Subcomponent

CVE-2023-32818  

A-294770901  
M-ALPS08013430, M-ALPS08163896 \*

High

vdec

CVE-2023-32847  

A-302982512  
M-ALPS08241940 \*

High

audio

CVE-2023-32848  

A-302982513  
M-ALPS08163896 \*

High

vdec

CVE-2023-32850  

A-302983201  
M-ALPS08016659 \*

High

decoder

CVE-2023-32851  

A-302986375  
M-ALPS08016652 \*

High

decoder

**Misc OEM**

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

   

CVE

References

Severity

Subcomponent

CVE-2023-45779  

A-301094654 \*

High

System UI

**Unisoc components**

These vulnerabilities affect Unisoc components and further details are available directly from Unisoc. The severity assessment of these issues is provided directly by Unisoc.

   

CVE

References

Severity

Subcomponent

CVE-2022-48456  

A-300376910  
U-1914157 \*

High

Kernel

CVE-2022-48461  

A-300368868  
U-1905646 \*

High

Kernel

CVE-2022-48454  

A-300382178  
U-2220123 \*

High

Android

CVE-2022-48455  

A-300385151  
U-2220123 \*

High

Android

CVE-2022-48457  

A-300368872  
U-2161952 \*

High

Android

CVE-2022-48458  

A-300368874  
U-2161952 \*

High

Android

CVE-2022-48459  

A-300368875  
U-2161952 \*

High

Android

**Qualcomm components**

These vulnerabilities affect Qualcomm 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

Subcomponent

CVE-2023-28588  

A-285902729  
QC-CR#3417458

High

Bluetooth

CVE-2023-33053  

A-299146326  
QC-CR#3453941

High

Kernel

CVE-2023-33063  

A-266568298  
QC-CR#3447219 \[2\]

High

Kernel

CVE-2023-33079  

A-299146464  
QC-CR#3446191

High

Audio

CVE-2023-33087  

A-299146536  
QC-CR#3508356 \[2\]

High

Kernel

CVE-2023-33092  

A-299146537  
QC-CR#3507292

High

Bluetooth

CVE-2023-33106  

A-300941008  
QC-CR#3612841

High

Display

CVE-2023-33107  

A-299649795  
QC-CR#3611296

High

Display

**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

Subcomponent

CVE-2022-40507  

A-261468680 \*

Critical

Closed-source component

CVE-2022-22076  

A-261469325 \*

High

Closed-source component

CVE-2023-21652  

A-268059928 \*

High

Closed-source component

CVE-2023-21662  

A-271879599 \*

High

Closed-source component

CVE-2023-21664  

A-271879160 \*

High

Closed-source component

CVE-2023-28546  

A-285902568 \*

High

Closed-source component

CVE-2023-28550  

A-280341535 \*

High

Closed-source component

CVE-2023-28551  

A-280341572 \*

High

Closed-source component

CVE-2023-28585  

A-285902652 \*

High

Closed-source component

CVE-2023-28586  

A-285903022 \*

High

Closed-source component

CVE-2023-28587  

A-285903202 \*

High

Closed-source component

CVE-2023-33017  

A-285902412 \*

High

Closed-source component

CVE-2023-33018  

A-285902728 \*

High

Closed-source component

CVE-2023-33022  

A-285903201 \*

High

Closed-source component

CVE-2023-33054  

A-295020170 \*

High

Closed-source component

CVE-2023-33080  

A-299147105 \*

High

Closed-source component

CVE-2023-33081  

A-299145668 \*

High

Closed-source component

CVE-2023-33088  

A-299146964 \*

High

Closed-source component

CVE-2023-33089  

A-299146027 \*

High

Closed-source component

CVE-2023-33097  

A-299147106 \*

High

Closed-source component

CVE-2023-33098  

A-299146466 \*

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 2023-12-01 or later address all issues associated with the 2023-12-01 security patch level.
*   Security patch levels of 2023-12-05 or later address all issues associated with the 2023-12-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\]:\[2023-12-01\]
*   \[ro.build.version.security\_patch\]:\[2023-12-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2023-12-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 2023-12-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 2023-12-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

December 4, 2023

Bulletin published

CVE-2023-45781: Android Security Bulletin—December 2023

The BGP daemon (bgpd) in IP Infusion ZebOS through 7.10.6 allow remote attackers to cause a denial of service by sending crafted BGP update messages containing a malformed attribute.

**Aug 29 2023**

Border Gateway Protocol is the de facto protocol that directs routing decisions between different ISP networks, and is generally known as the “glue” that holds the internet together. It’s safe to say that the internet we currently know would not function without working BGP implementations.

However, the software on those networks’ routers (I will refer to these as edge devices from now on) that implements BGP has not had a flawless track record. Flaws and problems do exist in commercial and open source implementations of the world’s most critical routing protocol.

Most of these flaws are of course benign in the grand scheme of things; they will be issues around things like route filtering, or insertion, or handling withdraws. However a much more scary issue is a BGP bug that can propagate after causing bad behaviour, akin to a computer worm.

While debugging support for a future feature for my business (bgp.tools) I took a brief diversion to investigate something, and what I came out with might be one of the most concerning things I’ve discovered for the reliability of the internet. To understand the problems, though, we will need a bit more context.

**A mistaken attribute**

On 2 June 2023, a small Brazilian network (re)announced one of their internet routes with a small bit of information called an attribute that was corrupted. The information on this route was for a feature that had not finished standardisation, but was set up in such a way that if an intermediate router did not understand it, then the intermediate router would pass it on unchanged.

As many routers did not understand this attribute, this was no problem for them. They just took the information and propagated it along. However it turned out that Juniper routers running even slightly modern software did understand this attribute, and since the attribute was corrupted the software in its default configuration would respond by raising an error that would shut down the whole BGP session. Since a BGP session is often a critical part of being “connected” to the wider internet, this resulted in the small Brazilian network disrupting other networks’ ability to communicate with the rest of the internet, despite being 1000’s of miles away.

A reader has pointed out that the attribute in question was not actually corrupted, but the support was just unfinished it appears

The packet that causes session shutdowns was really quite benign at first glance:

When a BGP session shuts down due to errors, customer network traffic generally stops flowing down that cable until the BGP connection is automatically restarted (typically within seconds to minutes).

This appears to be what happened to a number of different carriers, for example COLT was heavily impacted by this. Their outage is what originally drew some of my attention to this subject area.

To understand why this sort of thing can happen, we’ll need to take a deeper look at what BGP route attributes are, and what they’re used for.

**What is a BGP Route Attribute?**

At their core a BGP UPDATEs purpose is to tell another router about some traffic that it can (or can no longer) send to it. However just knowing directly what you can send to another router is not very useful without _context_.

For this reason a BGP packet is split up into two sections: the Network Layer Reachability Information (NLRI) data (aka, the IP address ranges), and the attributes that help describe extra context about that reachability data.

Arguably the most used attribute is the AS\_PATH (or actually, the AS4\_PATH), an attribute that tells you which networks a route has travelled through to get to you. Routers use this list of networks to pick paths for their traffic that are either the fastest, economically viable, or least congested, playing a critical role in ensuring that things run smoothly.

At the time of writing there are over 32 different route attribute types, 14 deprecated ones, and 209 officially unassigned ones. The Internet Assigned Numbers Authority (IANA) is in charge of assigning codes to each BGP attribute type codes, normally off the back of IETF Internet-Drafts. The IANA list doesn’t always give the full story, though, as not all internet-drafts make their way into more official documents (like RFC’s), so code numbers are assigned (or sometimes even “squatted”) to attribute types that did not get wide deployment.

**Unknown attribute propagation**

At the start of every route attribute is a set of flags, conveying information about the attribute. One important flag is called the “transitive bit”:

If a BGP implementation does not understand an attribute, and the transitive bit is set, it will copy it to another router. If the router does understand the attribute then it may apply its own policy.

At a glance this “feature” seems like an incredibly bad idea, as it allows possibly unknown information to propagate blindly through systems that do not understand the impact of what they are forwarding. However this feature has also allowed widespread deployment of things like Large Communities to happen faster, and has arguably made deployment of new BGP features possible at all.

**When attribute decoding goes wrong**

What happens when an attribute fails to decode? The answer depends strongly on if the BGP implementation has been updated to use RFC 7606 logic or not; If the session is _not_ RFC 7606 compliant, then typically an error is raised and the session is shut down. If it is, the session can usually continue as normal (except the routes impacted by the decoding error are treated as unreachable).

BGP session shutdowns are particularly undesirable, as they will impact traffic flow along a path. However in the case of a “Transitive” error they can become worm-like. Since not all BGP implementations support the same attributes, an attribute that is unknown to one implementation (and subsequently forwarded along) can cause another implementation to shut down the session it received it from.

With some reasonably educated crafting of a payload, someone could design a BGP UPDATE that “travels” along the internet unharmed, until it reaches a targeted vendor and results in that vendor resetting sessions. If that data comes down the BGP connections that are providing wider internet access for the network, this could result in a network being pulled offline from the internet.

This attack is not even a one-off “hit-and-run”, as the “bad” route is still stored in the peer router; when the session restarts the victim router will reset again the moment the route with the crafted payload is transmitted again. This has the potential to cause prolonged internet or peering outages.

This is a large part of why the RFC mentioned earlier, RFC 7606, exists; looking at its security considerations section, we can see a description of this exact problem::

> Security Considerations This specification addresses the vulnerability of a BGP speaker to a potential attack whereby a distant attacker can generate a malformed optional transitive attribute that is not recognized by intervening routers. Since the intervening routers do not recognize the attribute, they propagate it without checking it. When the malformed attribute arrives at a router that does recognize the given attribute type, that router resets the session over which it arrived. Since significant fan-out can occur between the attacker and the routers that do recognize the attribute type, this attack could potentially be particularly harmful.

In a basic BGP setup this is bad, but with extra engineering it could be used to partition large sections of the internet. If BGP sessions between carriers are forced to reset in this way, causing traffic flow to stop, some routes on the internet would not have alternatives to use, making this a family of bugs that is a grave threat to the overall reliability of the internet.

**Building a basic fuzzer**

**Important Commitment:** I run a business that involves being peered to many IXP route servers and other peoples routers. I have not and will not ever test for BGP bugs/exploits on customer/partner sessions (unless they give consent).

All testing here has been done either on GNS3 VMs, or physical hardware I have hanging around and in isolated VLANs.

To figure out if this would be a practically exploitable attack, I decided to write a fuzzer that would try to stuff random data in random attribute codes to see if I could get sessions to reset on different vendors BGP implementations.

Because I am looking for problems that are “wormable”, I added a Bird 2 router in between my fuzzer and the router being tested. This way Bird will filter out all of the obvious non-exploitable issues, and leave me with the packets that are of concern.

All good fuzzers should be able to run unattended, so how do we teach the fuzzer to tell if the session has reset itself? The solution I came to was that the Victim router would always announce a keepalive prefix, 192.0.2.0/24 (aka TEST-NET-1) and the fuzzer would treat a withdraw of that prefix (from the intermediate bird router) as a sign the session went down, and report back the parameters that caused that to happen!

Testing the fuzzer, I can see that the bird output shows unknown attributes as their type code, and a hex encoding of their contents. In addition it puts a [t] to indicate that it is transitive.

    198.51.100.0/24      unicast [fuzzer 21:31:24.378] * (100) [AS65001?]
    	via 192.168.5.1 on ens5
    	Type: BGP univ
    	BGP.origin: Incomplete
    	BGP.as_path: 65001
    	BGP.next_hop: 192.168.5.1
    	BGP.local_pref: 100
    	BGP.community: (123,2345)
    	BGP.ec [t]: 7d cc c7 30
    

Now that the fuzzer was able to run itself, all that was left was to test all of the vendors one by one…

**Fuzzer findings / Impacted Vendors**

Keep in mind that the described issues are applicable if you are running an edge device with full BGP tables. If you are not running a “full routing table” or a partial peering table, then you are less likely to be impacted by these discoveries.

Another thing to keep in mind, the issues below are different to the ones that the team at Forescout recently presented at BlackHat.

Unimpacted Vendors:

*   MikroTik RouterOS 7+
*   Ubiquiti EdgeOS
*   Arista EOS
*   Huawei NE40
*   Cisco IOS-XE / “Classic” / XR
*   Bird 1.6, All versions of Bird 2.0
*   GoBGP

**Juniper JunOS Impact**

Similar to the problem that caused this research to be done, another exploitable Attribute was found in the form of Attribute 29 (BGP-LS). Due to the nature of the attribute it is unlikely that an exploit attempt will propagate too far over the internet, however peering sessions and route servers are still at risk.

All Juniper users are **urged** to enable bgp-error-tolerance:

    [edit protocols bgp]
    root# show 
    group TRANSIT {
        import import-pol;
        export send-direct;
        peer-as 4200000001;
        local-as 4200000002;
        neighbor 192.0.2.2;
    }
    bgp-error-tolerance;
    

In all tested cases, enabling bgp-error-tolerance does not reset sessions, and applies the improved behaviour without restarting sessions.

A JunOS software release is expected in the future to correct this. One member of staff at Juniper has also authored an Internet-Draft at the IETF around handling these issues. Juniper is tracking this issue as CVE-2023-4481 / JSA72510.

**Nokia SR-OS Impact**

Fuzzing SR-OS (Version 22.10) revealed many, likely highly propagatable and thus exploitable attributes.

All Nokia SR-OS and SR-Linux users are **urged** to enable error-handling update-fault-tolerance on their devices.

     bgp
         group "TRANSIT"              
             export "yes"
             error-handling
                 update-fault-tolerance
             exit
             neighbor 192.0.2.2
                 peer-as 2
             exit
         exit
         no shutdown
     exit
    

In all tested cases, enabling update-fault-tolerance does not reset sessions, and applies the improved behaviour without restarting sessions.

To the best of my understanding, Nokia has no plans to correct these issues, instead suggesting customers apply error-handling update-fault-tolerance to their BGP groups.

**FRR Impact (and other downstream vendors)**

FRR attempts to handle bad attributes using RFC 7606 behaviour. However the fuzzer discovered that a corrupted attribute 23 (Tunnel Encapsulation) will cause a session to go down regardless.

After reporting this bug to FRR maintainers I received an acknowledgement of the issue and understanding that the issue is a DoS risk to FRR users, but I have not managed to get anything out of FRR since.

This bug is being tracked as CVE-2023-38802 and at the time of writing has no patch or fix.

FRR is packaged inside many other products, to name a few: SONIC, PICA8, Cumulus, and DANOS.

**OpenBSD OpenBGPd Impact**

OpenBGPd also supports the improved RFC 7606 behaviour, however it was found that the recently added Only To Customer implementation could cause session resets. This issue was very rapidly fixed after being reported to them, and is tracked as CVE-2023-38283.

OpenBSD users can install Errata 006 to mitigate this issue.

**Extreme Networks EXOS Impact**

As a result of fuzzing EXOS, the program revealed 2 highly propagatable and thus exploitable attributes in the form of:

*   Attribute 21: AS\_PATHLIMIT
*   Attribute 25: IPv6 Address Specific Extended Community

There is currently no known patch or mitigating config for this issue.

I made Extreme aware of this problem, however after a back and forth with them waiting for what I understood was an implied release of a patch or fix, they communicated that they will not be fixing it in the near future.

A quote from the security email thread (I’ve added emphasis to the critical parts of their response):

> After review of all the material, **we are not considering this a vulnerability due to the presence of RFC 7606**, as well as a history of documentation expressing these concerns all the way back to early 2000s, if not earlier. Malformed attributes are not a novel concept as an attack vector to BGP networks, as evidenced by RFC 7606, which is almost a decade old. As such, customers that have chosen to not require or implement RFC 7606 have done so willingly and with knowledge of what is needed to defend against these types of attacks. Thus, the expectation that we’ll reset our BGP sessions based on RFC 4271 attribute handling is proper. We do abide by other RFCs, in which we claim support, that update RFC 4271. Other vendors do claim RFC 7606 support and have been sharing these controls as a mitigation to malformed attribute response. They don’t appear to be producing new work product to account for these behaviors. **We are evaluating support for RFC 7606 as a future feature.** Obviously, if customers desire a different response, we’ll work through our normal feature request pipelines to address. This is no different than any other RFC support request.

I cannot overstate how much I disagree with Extreme’s response to this, and in the interests of full transparency (and to avoid any allegations of editorialising this, in my view, extremely poor response), I have made the full email exchange available here: (PDF).

**The Vendor Security Response**

I’ve been through my fair share of security issue discoveries, and over time I’ve taken a stronger leaning into “simply do not report” or “full disclosure without warning”, rather than the now commonly accepted 90 day “responsible disclosure” methodology. This is mostly because I’ve had really poor experiences when disclosing issues to security teams.

The bugs discussed in this post cover many vendors and implementations. Full disclosure was originally my plan, however due to the clear risk of harm to the general internet routing system from these findings, I felt it was likely inexcusable to do full-disclosure. (Plus, a malicious deployment of these findings could have a small but I believe very real chance of a “kinetic response” from a misunderstanding.)

Overall the response from vendors has been mostly disappointing. One vendor was extremely hard to find contacts for, and I feel that they were stringing me along for some time, only to reply back that they were not going to fix the problem.

Other vendors notably were not immediately interested in notifying customers of mitigating config to the problems, however when I personally started extending notices to my peers at larger carriers about the problems (since if they were not going to, I was going to try and reduce the exploit surface) a vendor notice was issued.

No vendor that I reported to has any form of bug bounty, and this entire adventure has consumed huge volumes of my time and mental capacity. In a normal situation this “cost” would have simply been eaten by an employer whose interest is name recognition or altruistic actions. However I am self-employed with my own company (that admittedly does have an interest in a functioning BGP ecosystem), and so this entire adventure has simply delayed product development that I (and customers) really would have liked to have done.

With all of that in mind, my “good faith” advice to people reporting security bugs in network vendor software is that contacting vendors is not an effective solution.

The people on the other side are either already overloaded, or generally don’t care about receiving issues. Since there is no motivation to report bugs (either in the form of bug bounties, or being treated well), I see no reason to do responsible disclosure (apart from cases where it would clearly protect their innocent customers from misery, while accounting for the risk of a vendor simply doing nothing).

The two options, as far as I see it, are either being strung along by a vendor over email for 90 days and then likely finding out nothing is done, or full disclosure.

I worry about the state of networking vendors.

With that being said, I would like to thank the OpenBSD security team, who very rapidly acknowledged my report, and prepared a patch. My only regret with dealing with the OpenBSD team was reporting the issue to them too quickly.

**Closing thoughts**

As mentioned before, with a few of the vendors (Nokia, Extreme, Juniper) I found myself contacting their own customers myself to warn them to enable mitigating config, as that proved to be a much more effective way at preventing risk than trying to push the vendor itself into action.

As a result at least several incumbent ISPs, 1 large CDN, and 2 “Tier 1” networks have applied configuration to help prevent these issues from impacting them.

If the goal of reporting security flaws is to reduce harm to their customers, I’m not convinced that reporting problems to vendors has enough of an effective impact to be worth doing, vs the loss of personal time and sanity.

Several people I spoke to have been incredibly helpful (some who could not be listed here). I would like to thank the following people for having some role in helping me either discover/disclose these problems, editing this post, or general support for when vendors were being very frustrating.

*   Basil Fillan
*   Alistair Mackenzie
*   Will Hargrave
*   Filippo Valsorda
*   Joseph Lorenzo Hall
*   Job Snijders
*   eta

If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Mastodon/Fediverse @benjojo@benjojo.co.uk

If you run a network and are interested in BGP monitoring do check out bgp.tools! Otherwise if you like what I do or think that you could do with some of my bizarre areas of knowledge I am also open for contract work, please contact me over at workwith@benjojo.co.uk!

Until next time!

CVE-2023-45886: Grave flaws in BGP Error handling

Chunghwa Telecom NOKIA G-040W-Q has a vulnerability of authentication bypass, which allows an unauthenticated remote attacker to bypass the authentication mechanism to log in to the device by an alternative URL. This makes it possible for unauthenticated remote attackers to log in as any existing users, such as an administrator, to perform arbitrary system operations or disrupt service.

:::

*   勒索軟體防護專區
*   遠距辦公資安專區
*   回首頁
*   網站導覽
*   訂閱電子報
*   English

****

*   資安通報
*   Wannacry
*   駭客
*   勒索
*   手機

*   新聞公告News
    *   公告事項
    *   資安新聞
    *   資安活動
    *   電子報
*   資安服務Services
    *   資安通報
        *   一般資安通報
    *   資安聯盟
        *   資安聯盟簡介
        *   規章及會員申請暨異動申請
    *   台灣漏洞揭露平台 (TVN)
        *   TVN (Taiwan Vulnerability Note) 漏洞公告
        *   漏洞揭露政策
        *   漏洞通報
    *   惡意檔案檢測服務 (Virus Check)
    *   網路釣魚通報 (Phishing Check)
        *   網路釣魚通報
        *   釣魚網站列表
*   資安宣導Advocacy
    *   勒索軟體威脅防護專區
    *   遠距辦公資安專區
    *   企業資安事件應變處理指南
    *   威脅分析報告
    *   資安小知識
    *   資訊安全宣導
    *   資安宣導影音
    *   公開文件
*   相關網站Links
    *   國內資安組織
    *   國際資安組織
    *   網路資源
*   關於我們About us
    *   中心簡介
    *   活動紀事
        *   歷年年會活動網站
        *   活動花絮
    *   PGP KEY
    *   聯絡我們
    *   合作夥伴

:::

*   首頁
*   資安服務
*   台灣漏洞揭露平台 (TVN)
*   TVN (Taiwan Vulnerability Note) 漏洞公告

TVN ID

TVN-202311007

CVE ID

CVE-2023-41351

CVSS

9.8 (Critical)  
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

影響產品

NOKIA G-040W-Q: G040WQR201207

問題描述

中華電信 NOKIA G-040W-Q 存在 Authentication Bypass漏洞。未經驗證的遠端攻擊者能以任意使用者身份(包含管理者)bypass 驗證機制，以特殊URL登入系統。若攻擊者以管理者身份登入系統，則能執行任意系統指令，對系統進行控制，並中斷服務。

解決方法

更新韌體版本至G040WQR231013

漏洞通報者

Ta-Lun Yen(TXOne Networks)

公開日期

2023-11-03

Tag

#nokia