At the heart of every application are secrets. Credentials that allow human-to-machine and machine-to-machine communication. Machine identities outnumber human identities by a factor of 45-to-1 and represent the majority of secrets we need to worry about. According to CyberArk's recent research, 93% of organizations had two or more identity-related breaches in the past year. It is clear that we

At the heart of every application are secrets. Credentials that allow human-to-machine and machine-to-machine communication. Machine identities outnumber human identities by a factor of 45-to-1 and represent the majority of secrets we need to worry about. According to CyberArk's recent research, 93% of organizations had two or more identity-related breaches in the past year. It is clear that we need to address this growing issue. Additionally, it is clear that many organizations are OK with using plaintext credentials for these identities in private repos, thinking they will stay private. However, poor hygiene in private code leads to public leaks, as we see in the news too often. Given the scope of the problem, what can we do?

What we really need is a change in our processes, especially around the creation, storage, and working with machine identities. Fortunately, there is a clear path forward, combining existing secrets management solutions and secret detection and remediation tools, all while meeting the developers where they are.

**Making an end-to-end secrets security game plan**

When we think of remediating the machine identity problem, also known as secrets sprawl, we can lay out the problem in a couple sentences.

"_We have an unknown number of valid long-lived plaintext secrets spread throughout our code, configurations, CI pipelines, project management systems, and other sources, which we can not account for, and without a coherent rotation strategy. Meanwhile, developers continue to work with secrets in plaintext since it is a reliable, although problematic, way to get the application to work._"

Thinking through this working definition, we can make a multi-step plan to address each concern.

1.  Secrets Detection - Search through code and systems involved in the software development lifecycle to identify existing plaintext credentials, gathering as much information as possible about each.
2.  Secrets Management - Accounting for all known secrets through a centralized vault platform.
3.  Developer Workflows - Adjust processes and tools to make it easier to properly create, store, and call secrets securely.
4.  Secrets Scanning - Continuously monitoring for any new secrets that get added in plain text.
5.  Automatic Rotation - Regular replacement of valid secrets shortens their potential exploitation by malicious actors.

You can take this journey one step at a time, treating this as a phased rollout. Before you know it, you will be much closer to eliminating secrets sprawl and securing all your machine identities.

**Finding your secrets**

The first problem every team encounters when trying to get a handle on secret sprawl is determining what secrets they even have. A manual search effort to track down unknown secrets would quickly overwhelm any team, but fortunately, there are secrets scanning tools, such as GitGuardian's, that can automate this process and give insight into critical details. From a stable platform, you should provide a communication path to work with the developers for remediation.

**Implementing a centralized secrets vault**

Central to any good secrets management strategy is managing how secrets are stored and utilized. Enterprise vaults transparently allow you to account for all known secrets, encrypting them at rest and in transit. A good vault solution, including Conjure from Cyberark and Hashicorp Vault Enterprise. If all of your infrastructure is from the same provider, such as AWS or GCP, those are very good options as well.

**Securing the developer workflow**

Secrets management has historically been left in the hands of developers to figure out, leading to a wide variety of solutions like \`.env\` files and, unfortunately, hardcoding secrets into the codebase. Leveraging a centralized vault solution gives developers a consistent way to safely invoke the credentials from their applications throughout all environments. If you can offer a standardized approach that is just as easy to implement as what they are currently doing, you will find many developers will jump at the chance to guarantee their deployments are not blocked due to this security concern.

You will also want to consider shifting left. Command-line tools, such as ggshield, allow developers to add automatic Git hooks to scan for plaintext credentials before any commit is made. Stopping a secret from ever reaching a commit means no incident to deal with later and fixing the problem at the least expensive point in the software development life cycle.

**Secret scanning at every shared interaction**

You also need a way to account for the reality that sometimes accidents happen. Ongoing monitoring is needed to watch for any new issues that come from existing devs making a mistake or when new teams or subcontractors are hired who simply don't know your processes yet. Just as when first doing secrets detection, using a platform that gathers the information into a coherent incident will help you respond rapidly to these new issues. GitGuardian, for example, integrates at the code repository level to catch new plaintext credentials in seconds, automatically at every push or comment.

**Short-lived credentials should be the goal of automatic rotation**

If an attacker finds a valid secret, that makes their job a lot simpler, as they can just unlock any doors they encounter. If that same attacker finds an invalid secret, they can't do much with it. With a centralized vault in place, you can put auto-rotation plans in place. Most modern platforms and services have a way to generate new credentials through an API call and a way to invalidate existing secrets. With a little scripting, following one of the many guides put out by platforms such as AWS or CyberArk, it is possible to automate the safe replacement of any credential on a regular, even daily, schedule.

**End-to-end secrets security requires a plan**

The best time to address the issues surrounding end-to-end secrets security is right now. If you do not already have a game plan in place, today is the best time to start having those conversations. Start by asking questions like" "what secrets do we even have?" or "Do you have a vault in place?" Ultimately, we must empower developers with workflows and guardrails that let them focus on their development flow.

Keeping vigilant that new secrets are discovered and dealt with immediately is an ongoing process. it will take effort, including raising awareness and adopting the right processes and technologies, but any company can get a better handle on machine identities and secrets, end to end, across the organization.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

End-to-End Secrets Security: Making a Plan to Secure Your Machine Identities

The ransomware group claimed it had breached the Federal Reserve, but the target now appears to have been an Arkansas-based bank, Evolve.

Source: Anthony Pierce via Alamy Stock Photo

Evolve Bank, a financial institution headquartered in Arkansas, was the victim of an attack by the LockBit ransomware group which resulted in a data leak onto the Dark Web this week.

LockBit had drawn attention to itself earlier this week after claiming to have hacked the US Federal Reserve.

The announcement was seen by some within the IT security community as a bold — some used the word "desperate"­ — comeback attempt following the recent, high-profile law enforcement takedown of the ransomware giant. 

After publishing a post on its data leak site threatening to release "33 terabytes of juicy banking information containing Americans' banking secrets" if a ransom was not paid, LockBit then released some of the data, which was actually stolen from Evolve.

"It appears these bad actors have released illegally obtained data, including personal identification information (PII), on the Dark Web," according to an Evolve statement. "The data varies by individual, but may include your name, Social Security number, date of birth, account information and/or other personal information."

The statement noted the company had contacted law enforcement authorities as part of the bank's investigation and response efforts.

"Based on what our investigation has found and what we know at this time, we are confident this incident has been contained and there is no ongoing threat," the statement said.

The company added that retail banking customers’ debit cards, online, and digital banking credentials did not seem to be affected by the breach.

"Those credentials appear to be secure," a statement said.

**Evolve Already Target of Fed Action**

Earlier this month, the Federal Reserve Board issued an enforcement action against Evolve Bancorp and Evolve Bank & Trust, accusing the company of deficiencies in their anti-money laundering, risk management, and consumer compliance programs.

"Examinations conducted in 2023 found Evolve did not maintain an effective risk-management program or controls sufficient to comply with anti-money laundering laws and laws protecting consumers," the Fed statement read.

Stephen Gates, principal security SME for Horizon3.ai, said in an emailed statement that once an organization experiences a breach, and the smoke begins to clear, the biggest decision is what to do next.

"Everything in the networking environment is now suspect, possibly riddled with other exploitable vulnerabilities and weaknesses that likely remain hidden," he said.

That means that teams must find the attack path that allowed the breach to happen, and they need to uncover other attack paths that could enable it to happen again.

"Now is the time to thoroughly assess the entire networking environment, both on-premises and cloud, but that could take months if not longer," Gates said.

**Financial Sector Defenses Must Evolve**

Piyush Pandey, CEO at Pathlock, says the recent enforcement action against Evolve Bancorp underscores the critical importance of robust sensitive data and application access controls within financial institutions.

"As traditional banking continues to intersect with innovative fintech solutions, maintaining stringent identity and access controls is a must," he says.

He also points out that the interconnectedness and complexity of supply chains in the financial sector increases the difficulty of managing and securing third-party access.

"Given how highly regulated the financial sector is with regards to data protection and privacy, ensuring that third-party vendors comply with these regulations is crucial, yet challenging," Pandey explains.

He adds that by focusing on rigorous controls testing and enforcement, including stringent management of third-party identities and access, financial institutions can significantly strengthen their security posture, protect sensitive data, and ensure compliance with regulatory requirements.

"This proactive approach not only safeguards customer data — and trust — but also enhances the institution's overall resilience against these types of attacks," Pandey says.

Narayana Pappu, CEO at Zendata, notes that financial and medical institutions store significant amount highly sensitive data with significant monetary impact for exposed organizations.

"Therefore, it makes sense that organizations like LockBit are going after this information," he says.

From his perspective, data minimization — not capturing or storing data that is not needed — would help these institutions significantly.

"The trend to date has been to capture, store and make multiple copies of information that is not really needed to run the business," Pappu says. "Just 5% of data collected is properly labeled and governed, for example."

**About the Author(s)**

Nathan Eddy is a freelance journalist and award-winning documentary filmmaker specializing in IT security, autonomous vehicle technology, customer experience technology, and architecture and urban planning. A graduate of Northwestern University’s Medill School of Journalism, Nathan currently lives in Berlin, Germany.

LockBit Attack Targets Evolve Bank, Not Federal Reserve

Responding to an incident quickly is important, but it shouldn't come at the expense of reporting it to the appropriate regulatory bodies.

Source: Nico El Nino via Alamy Stock Photo

When the Intercontinental Exchange (ICE) identified a breach in its virtual private network (VPN), the organization immediately launched investigation and remediation efforts. However, it was not until four days later that the company reported the breach to regulators, violating not only the Security and Exchange Commission's (SEC) compliance requirements but also the company's own internal cyber incident reporting procedures. This is according to the SEC in its May announcement of a $10 million fine. The question of why ICE delayed reporting the incident was never answered publicly.

The SEC stated: "The SEC's order finds that ICE personnel did not notify the legal and compliance officials at ICE's subsidiaries of the intrusion for several days in violation of ICE’s own internal cyber incident reporting procedures. As a result of ICE's failures, those subsidiaries did not properly assess the intrusion to fulfill their independent regulatory disclosure obligations under Regulation SCI (Regulation Systems Compliance and Integrity), which required them to immediately contact SEC staff about the intrusion and provide an update within 24 hours unless they immediately concluded or reasonably estimated that the intrusion had or would have no or a de minimis impact on their operations or on market participants."

Both ICE and the SEC declined to answer Dark Reading's inquiries, but there are some possible explanations. It is also a cautionary tale for other critical infrastructure organizations that consider bypassing compliance for quicker incident response.

A popular misconception is that enterprises have a cavalier attitude about compliance and think that it is easier to pay the fine and chance the consequences of bad press and lawsuits, rather than file the necessary compliance documents and deal with the outcome of suffering a breach.

"I've never been in a situation or a meeting where someone has seriously said, 'Well, we'll just pay the fine,'" says Fred Rica, a partner at certified public accounting firm BPM Associates. "I think most boards and management committees strive to do the right thing and abide by the rules and regulations that they're bound to."

The challenge remains that nontechnical board members often do not understand cybersecurity implications, while CISOs may struggle to explain threats in business terms. Rica emphasizes the need for boards to ask better questions and be more engaged with cybersecurity issues. 

"The first thing that has to change is, boards need to start asking better questions," he says, adding that the time where boards could pass off cyber threats to the technical team has passed.

"What was sufficient even three years ago probably is not sufficient anymore," Rica says.

In the case of ICE, the VPN attack turned out to have “de minimis impact on their operations or on market participants," the SEC said. While that alone does not change the need to report attacks against critical infrastructure within 24 hours, it could indicate that the company focused on fixing a problem as quickly as possible. Or it simply might mean that the company dropped the ball on what should have been a task that should have been done within 24 hours.

A company that doesn't report a data breach could face greater scrutiny of its cyber insurance policy. Companies with adequate security controls get better rates and terms on their cyber policies, while those with shortcomings face higher rates and less favorable terms, notes Bridget Quinn Choi, an attorney at Woodruff-Sawyer & Co.

In this case, she says, ICE was on top of the incident almost immediately.

"They had a criticality matrix. They had reporting controls, they were looking at the severity, and they fairly quickly went in and found the vulnerability. They found that there was a minor intrusion, and they remediated so quickly," she says. "It wasn't a big deal. So it was a pretty good result from an incident response perspective. The thing that was missing is that in their incident response plan, they had to report within 24 hours if there was a reasonable suspicion of an intrusion. They didn't do it."

Choi notes that while the response was fast, the company had procedural issues.

"Even the SEC came back and said this was de minimis. But it's their second violation," she says. (The company previously violated the SEC's Regulation SCI for failing to have appropriate backup and backup procedures.)

"I think that there's a common misconception that cyber is an infosec issue," she says.

Rather, cybersecurity is a business process that can have a wide-ranging effect on the company, its reputation, and revenue.

"The impact to the company can be wide-ranging," she says. There can be cascading costs, there's regulatory issues, \[and\] there's a plaintiff's bar that is hungry to get into this game. So it's not just doing things, right? It's doing things right."

**About the Author(s)**

Stephen Lawton is a veteran journalist and cybersecurity subject matter expert who has been covering cybersecurity and business continuity for more than 30 years. He was named a Global Top 25 Data Expert for 2023 and a Global Top 20 Cybersecurity Expert for 2022. Stephen spent more than a decade with SC Magazine/SC Media/CyberRisk Alliance, where he served as editorial director of the content lab. Earlier he was chief editor for several national and regional award-winning publications, including MicroTimes and Digital News & Review. Stephen is the founder and senior consultant of the media and technology firm AFAB Consulting LLC. You can reach him at \[email protected\].

Don't Forget to Report a Breach: A Cautionary Tale

The attacks infiltrate enterprise networks through browsers, and show an evolution in evasive and adaptive tactics from well-resourced state-sponsored actors.

Source: Rawpixel.com via Shutterstock

Three novel credential-phishing campaigns have emerged from state-sponsored actors that have compromised at least 40,000 corporate users — including top-level executives — in just three months' time, researchers have found.

The attacks target a range of industries and enter corporate environments through browsers, allowing them to get past network infrastructure security controls and cloud network services and demonstrating an evolution in capabilities on the part of adversaries, according to researchers from Menlo Security who discovered them.

The campaigns — called LegalQloud, Eqooqp, and Boomer — are characterized by their deployment of what the researchers call highly evasive and adaptive threat (HEAT) attack techniques that can circumvent controls such as multifactor authentication (MFA) and URL filtering.

Tactics used by the campaigns include bypassing MFA and using phishing kits and adversary-in-the-middle (AitM) tactics to take over user sessions; impersonating entities, primarily Microsoft, familiar to or associated with the organizations targeted; and using dynamic phishing links that make it hard for filtering technologies to track and thus detect.

"These are challenging new tactics, and security practitioners must augment controls and take care to address them immediately," according to the report. "These sophisticated attacks magnify concerns about the effectiveness of traditional network security controls such as secure service Edge (SSE), secure Web gateways (SWG), and endpoint detection and response (EDR)."

**State-Sponsored Actors Get Aggressive**

The campaigns are aimed exclusively at credential phishing, with evidence to connect them to China-sponsored threat actors who are targeting the US and private enterprise in "aggressive cyber espionage efforts, posing an alarming risk to national security and pilfering innovation," according to the report. However, though researchers have established some attribution to a group previously tracked by Microsoft as Storm-1101/DEV-1101 — known for its development of AitM tactics that are used in the campaigns — it's not entirely clear exactly to which nation the attacks are linked.

All told, the campaigns targeted more than 3,000 unique domains across more than 10 industries and government institutions, and six out of 10 malicious links that users clicked on were connected to some kind of phishing campaign or fraud, with one of four of phishing links getting past legacy URL filtering, the researchers found.

Overall, this activity demonstrates how "nation-state cyber actors are constantly refining their methods to make their attacks more sophisticated and adaptable," notes Patrick Tiquet, vice president, security and architecture, at Keeper Security. This, in turn, means enterprises must accept that "adapting cybersecurity strategies is an ongoing process that demands flexibility and agility," he says.

**Specific Credential-Stealing Campaigns**

Though the campaigns have similarities, each has its own unique set of targets and tactics, all with the ultimate goal of extracting credentials from corporate users for further malicious purposes, primarily cyber-espionage.

LegalQloud, so-named because it impersonates legal firms to steal Microsoft credentials, targeted 500 enterprises in 90 days and is exclusively hosted on Tencent Cloud, which is from the largest Internet company in China. This hosting enables the URLs to bypass traditional categorization and allow-list controls, the researchers said.

Eqooqp has been targeting multiple government and private sector organizations — including logistics, finance, petroleum, manufacturing, higher education, and research firms — with AitM attacks that can defeat MFA. Menlo found nearly 50,000 attacks associated with the campaign, which uses malicious HTML attachments or links to pages that mimic Microsoft to phish credentials.

Another phishing campaign, Boomer, is especially intricate, targeting the government and healthcare sectors with advanced evasive techniques that include dynamic phishing sites, custom HTTP headers, tracking cookies, bot-detection countermeasures, encrypted code, and server-side generated phishing pages.

"Boomer uses server-side generated phishing pages for rapid campaign deployment and modification, enhancing the campaign’s ability to evade traditional security tools, indicating a higher level of skill," according to the report. "Boomer also includes properly configured security headers, such as X-XSS-Protection, and uses legitimate libraries, like Font Awesome for icons."

The campaign's Web application also employs a hidden iframe that's designed to detect bots and scan automation as a further advanced evasion tactic, the researchers found.

**Demand for Stronger Defense**

What all this amounts to is that organizations continue to have their work cut out for them to keep up with the evolving nature of attacks, especially from well-resourced state-sponsored actors, security experts say.

AitM attacks in particular — in which attackers deploy a proxy server between a target user and the website the user wishes to visit — "are the future of cybercrime," notes one security expert, and will be a particular thorn in the side of organizations' security strategies going forward.

"\[They\] are extremely effective and much harder to trace and prevent compared to traditional social engineering attacks," says Mika Aalto, co-founder and CEO at human risk management platform firm Hoxhunt.

And while they historically have been technically difficult to achieve for attackers, their recent prevalence shows that threat actors are quickly navigating this barrier, which will bring on "a wave of serious breaches from AitM-integrated credential harvesters, BECs, and ransomware," he says.

"The bottom line is, you have to accept that some attacks will get through to your users and thus you must do your best to prepare them for that fateful moment," Aalto says. "Security awareness and phishing training must keep pace with the latest threats so that people understand AitM and dynamic phishing, and they know how to spot these attacks and stay safe. Indeed, as cybersecurity is now a matter of national security and not just about protecting an organization's own data, it must be treated with the highest priority," Tiquet observes.

This requires organizations to embrace a zero-trust framework that "must evolve alongside technological advancements, workflow changes and shifts in the threat landscape," Tiquet says, and be continually refined and adapted "to ensure it remains effective in mitigating risks and protecting sensitive information."

**About the Author(s)**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

China-Sponsored Attackers Target 40K Corporate Users in 90 Days

Red Hat Security Advisory 2024-4108-03 - An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4108.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel security and bug fix update  
Advisory ID:        RHSA-2024:4108-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:4108  
Issue date:         2024-06-26  
Revision:           03  
CVE Names:          CVE-2021-47400  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: netfilter: nf_tables: use timestamp to check for set element timeout (CVE-2024-27397)

* kernel: xen-netfront: Add missing skb_mark_for_recycle (CVE-2024-27393)

* kernel: netfilter: nft_flow_offload: reset dst in route object after setting up flow (CVE-2024-27403)

* kernel: smb: client: fix UAF in smb2_reconnect_server() (CVE-2024-35870)

* kernel: net/mlx5: Properly link new fs rules into the tree (CVE-2024-35960)

* kernel: net: ena: Fix incorrect descriptor free behavior (CVE-2024-35958)

* kernel: net: hns3: do not allow call hns3_nic_net_open repeatedly (CVE-2021-47400)

* kernel: octeontx2-af: avoid off-by-one read from userspace (CVE-2024-36957)

Bug Fix(es):

* lpfc updates for rh9.4 - (14.2.0.15 14.2.0.16 patches) (JIRA:RHEL-35144)

* cifs - kernel panic with cifs_put_smb_ses (JIRA:RHEL-25787)

* Rhel-9.2- observed \"vas: Failed reconfig VAS capabilities with DLPAR \" message while running proc add rem mix operations in shared mode[5.14.0-252.el9.ppc64le][P9] (JIRA:RHEL-34086)

* CNB95: dpll: rebase DPLL to upstream v6.8 (JIRA:RHEL-36570)

* Boot process stalls during initial loading of RHEL9.2 between the 59th and 100th AC cycle (JIRA:RHEL-36681)

* ice: DPLL-related fixes (JIRA:RHEL-36714)

* [HPE RHEL 9.2 BUG] x86/platform/uv: UV support for sub-NUMA clustering (JIRA:RHEL-37595)

* CNB95: net/sched: update TC core to upstream v6.8 (JIRA:RHEL-37640)

* [ice] Entering Safe Mode because DDP package could not be loaded and hit panic then (JIRA:RHEL-38906)

* [ice] Add automatic VF reset on Tx MDD events (JIRA:RHEL-39082)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-47400

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2280434  
https://bugzilla.redhat.com/show_bug.cgi?id=2280745  
https://bugzilla.redhat.com/show_bug.cgi?id=2281127  
https://bugzilla.redhat.com/show_bug.cgi?id=2281740  
https://bugzilla.redhat.com/show_bug.cgi?id=2281920  
https://bugzilla.redhat.com/show_bug.cgi?id=2281925  
https://bugzilla.redhat.com/show_bug.cgi?id=2282336  
https://bugzilla.redhat.com/show_bug.cgi?id=2284581

Red Hat Security Advisory 2024-4108-03

Red Hat Security Advisory 2024-4106-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4106.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: kernel-rt security update  
Advisory ID:        RHSA-2024:4106-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:4106  
Issue date:         2024-06-26  
Revision:           03  
CVE Names:          CVE-2021-47400  
====================================================================

Summary: 

An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

* kernel: netfilter: nf_tables: use timestamp to check for set element timeout (CVE-2024-27397)

* kernel: xen-netfront: Add missing skb_mark_for_recycle (CVE-2024-27393)

* kernel: netfilter: nft_flow_offload: reset dst in route object after setting up flow (CVE-2024-27403)

* kernel: smb: client: fix UAF in smb2_reconnect_server() (CVE-2024-35870)

* kernel: net/mlx5: Properly link new fs rules into the tree (CVE-2024-35960)

* kernel: net: ena: Fix incorrect descriptor free behavior (CVE-2024-35958)

* kernel: net: hns3: do not allow call hns3_nic_net_open repeatedly (CVE-2021-47400)

* kernel: octeontx2-af: avoid off-by-one read from userspace (CVE-2024-36957)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2021-47400

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2280434  
https://bugzilla.redhat.com/show_bug.cgi?id=2280745  
https://bugzilla.redhat.com/show_bug.cgi?id=2281127  
https://bugzilla.redhat.com/show_bug.cgi?id=2281740  
https://bugzilla.redhat.com/show_bug.cgi?id=2281920  
https://bugzilla.redhat.com/show_bug.cgi?id=2281925  
https://bugzilla.redhat.com/show_bug.cgi?id=2282336  
https://bugzilla.redhat.com/show_bug.cgi?id=2284581

Red Hat Security Advisory 2024-4106-03

Affected devices could include wireless access points, routers, switches and VPNs.

Multiple vulnerabilities in TP-Link Omada system could lead to root access

Ubuntu Security Notice 6819-4 - Alon Zahavi discovered that the NVMe-oF/TCP subsystem in the Linux kernel did not properly validate H2C PDU data, leading to a null pointer dereference vulnerability. A remote attacker could use this to cause a denial of service. Chenyuan Yang discovered that the RDS Protocol implementation in the Linux kernel contained an out-of-bounds read vulnerability. An attacker could use this to possibly cause a denial of service.

    ==========================================================================Ubuntu Security Notice USN-6819-4June 26, 2024linux-oracle-6.5 vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 22.04 LTSSummary:Several security issues were fixed in the Linux kernel.Software Description:- linux-oracle-6.5: Linux kernel for Oracle Cloud systemsDetails:Alon Zahavi discovered that the NVMe-oF/TCP subsystem in the Linux kerneldid not properly validate H2C PDU data, leading to a null pointerdereference vulnerability. A remote attacker could use this to cause adenial of service (system crash). (CVE-2023-6356, CVE-2023-6535,CVE-2023-6536)Chenyuan Yang discovered that the RDS Protocol implementation in the Linuxkernel contained an out-of-bounds read vulnerability. An attacker could usethis to possibly cause a denial of service (system crash). (CVE-2024-23849)It was discovered that a race condition existed in the Bluetooth subsystemin the Linux kernel, leading to a null pointer dereference vulnerability. Aprivileged local attacker could use this to possibly cause a denial ofservice (system crash). (CVE-2024-24860)Several security issues were discovered in the Linux kernel.An attacker could possibly use these to compromise the system.This update corrects flaws in the following subsystems:   - ARM64 architecture;   - PowerPC architecture;   - RISC-V architecture;   - S390 architecture;   - Core kernel;   - x86 architecture;   - Block layer subsystem;   - Cryptographic API;   - ACPI drivers;   - Android drivers;   - Drivers core;   - Power management core;   - Bus devices;   - Device frequency scaling framework;   - DMA engine subsystem;   - EDAC drivers;   - ARM SCMI message protocol;   - GPU drivers;   - IIO ADC drivers;   - InfiniBand drivers;   - IOMMU subsystem;   - Media drivers;   - Multifunction device drivers;   - MTD block device drivers;   - Network drivers;   - NVME drivers;   - Device tree and open firmware driver;   - PCI driver for MicroSemi Switchtec;   - Power supply drivers;   - RPMSG subsystem;   - SCSI drivers;   - QCOM SoC drivers;   - SPMI drivers;   - Thermal drivers;   - TTY drivers;   - VFIO drivers;   - BTRFS file system;   - Ceph distributed file system;   - EFI Variable file system;   - EROFS file system;   - Ext4 file system;   - F2FS file system;   - GFS2 file system;   - JFS file system;   - Network file systems library;   - Network file system server daemon;   - File systems infrastructure;   - Pstore file system;   - ReiserFS file system;   - SMB network file system;   - BPF subsystem;   - Memory management;   - TLS protocol;   - Ethernet bridge;   - Networking core;   - IPv4 networking;   - IPv6 networking;   - Logical Link layer;   - MAC80211 subsystem;   - Multipath TCP;   - Netfilter;   - NetLabel subsystem;   - Network traffic control;   - SMC sockets;   - Sun RPC protocol;   - AppArmor security module;   - Intel ASoC drivers;   - MediaTek ASoC drivers;   - USB sound devices;(CVE-2023-52612, CVE-2024-26808, CVE-2023-52691, CVE-2023-52618,CVE-2023-52463, CVE-2023-52447, CVE-2024-26668, CVE-2023-52454,CVE-2024-26670, CVE-2024-26646, CVE-2023-52472, CVE-2024-26586,CVE-2023-52681, CVE-2023-52453, CVE-2023-52611, CVE-2023-52622,CVE-2024-26641, CVE-2023-52616, CVE-2024-26592, CVE-2023-52606,CVE-2024-26620, CVE-2023-52692, CVE-2024-26669, CVE-2023-52623,CVE-2023-52588, CVE-2024-26616, CVE-2024-26610, CVE-2024-35839,CVE-2023-52490, CVE-2023-52672, CVE-2024-26612, CVE-2023-52617,CVE-2023-52697, CVE-2024-26644, CVE-2023-52458, CVE-2023-52598,CVE-2024-35841, CVE-2023-52664, CVE-2023-52635, CVE-2023-52676,CVE-2023-52669, CVE-2024-26632, CVE-2023-52486, CVE-2024-26625,CVE-2023-52608, CVE-2024-26634, CVE-2023-52599, CVE-2024-26618,CVE-2024-26640, CVE-2023-52489, CVE-2023-52675, CVE-2023-52678,CVE-2024-26583, CVE-2023-52693, CVE-2023-52498, CVE-2024-26649,CVE-2023-52670, CVE-2023-52473, CVE-2023-52449, CVE-2023-52667,CVE-2023-52467, CVE-2023-52686, CVE-2024-26633, CVE-2023-52666,CVE-2024-35840, CVE-2024-26629, CVE-2024-26595, CVE-2023-52593,CVE-2023-52687, CVE-2023-52465, CVE-2024-26627, CVE-2023-52493,CVE-2023-52491, CVE-2024-26636, CVE-2024-26584, CVE-2023-52587,CVE-2023-52597, CVE-2023-52462, CVE-2023-52633, CVE-2023-52696,CVE-2024-26585, CVE-2023-52589, CVE-2023-52456, CVE-2023-52470,CVE-2024-35838, CVE-2024-26645, CVE-2023-52591, CVE-2023-52464,CVE-2023-52609, CVE-2024-26608, CVE-2023-52450, CVE-2023-52584,CVE-2023-52469, CVE-2023-52583, CVE-2023-52451, CVE-2023-52495,CVE-2023-52626, CVE-2023-52595, CVE-2023-52680, CVE-2023-52632,CVE-2024-26582, CVE-2024-35837, CVE-2023-52494, CVE-2023-52614,CVE-2023-52443, CVE-2023-52698, CVE-2023-52448, CVE-2024-26615,CVE-2023-52452, CVE-2023-52492, CVE-2024-26647, CVE-2023-52468,CVE-2023-52594, CVE-2023-52621, CVE-2024-26638, CVE-2024-26594,CVE-2024-26673, CVE-2023-52457, CVE-2023-52677, CVE-2023-52607,CVE-2024-26623, CVE-2023-52488, CVE-2023-52497, CVE-2023-52445,CVE-2024-26607, CVE-2023-52610, CVE-2024-35842, CVE-2023-52690,CVE-2023-52683, CVE-2023-52444, CVE-2024-26671, CVE-2023-52455,CVE-2023-52679, CVE-2024-26598, CVE-2023-52674, CVE-2023-52627,CVE-2023-52619, CVE-2023-52487, CVE-2023-52446, CVE-2024-35835,CVE-2023-52682, CVE-2023-52685, CVE-2023-52694, CVE-2024-26631)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 22.04 LTS   linux-image-6.5.0-1024-oracle   6.5.0-1024.24~22.04.1   linux-image-6.5.0-1024-oracle-64k  6.5.0-1024.24~22.04.1   linux-image-oracle              6.5.0.1024.24~22.04.1   linux-image-oracle-64k          6.5.0.1024.24~22.04.1After a standard system update you need to reboot your computer to makeall the necessary changes.ATTENTION: Due to an unavoidable ABI change the kernel updates havebeen given a new version number, which requires you to recompile andreinstall all third party kernel modules you might have installed.Unless you manually uninstalled the standard kernel metapackages(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,linux-powerpc), a standard system upgrade will automatically performthis as well.References:   https://ubuntu.com/security/notices/USN-6819-4   https://ubuntu.com/security/notices/USN-6819-1   CVE-2023-52443, CVE-2023-52444, CVE-2023-52445, CVE-2023-52446,   CVE-2023-52447, CVE-2023-52448, CVE-2023-52449, CVE-2023-52450,   CVE-2023-52451, CVE-2023-52452, CVE-2023-52453, CVE-2023-52454,   CVE-2023-52455, CVE-2023-52456, CVE-2023-52457, CVE-2023-52458,   CVE-2023-52462, CVE-2023-52463, CVE-2023-52464, CVE-2023-52465,   CVE-2023-52467, CVE-2023-52468, CVE-2023-52469, CVE-2023-52470,   CVE-2023-52472, CVE-2023-52473, CVE-2023-52486, CVE-2023-52487,   CVE-2023-52488, CVE-2023-52489, CVE-2023-52490, CVE-2023-52491,   CVE-2023-52492, CVE-2023-52493, CVE-2023-52494, CVE-2023-52495,   CVE-2023-52497, CVE-2023-52498, CVE-2023-52583, CVE-2023-52584,   CVE-2023-52587, CVE-2023-52588, CVE-2023-52589, CVE-2023-52591,   CVE-2023-52593, CVE-2023-52594, CVE-2023-52595, CVE-2023-52597,   CVE-2023-52598, CVE-2023-52599, CVE-2023-52606, CVE-2023-52607,   CVE-2023-52608, CVE-2023-52609, CVE-2023-52610, CVE-2023-52611,   CVE-2023-52612, CVE-2023-52614, CVE-2023-52616, CVE-2023-52617,   CVE-2023-52618, CVE-2023-52619, CVE-2023-52621, CVE-2023-52622,   CVE-2023-52623, CVE-2023-52626, CVE-2023-52627, CVE-2023-52632,   CVE-2023-52633, CVE-2023-52635, CVE-2023-52664, CVE-2023-52666,   CVE-2023-52667, CVE-2023-52669, CVE-2023-52670, CVE-2023-52672,   CVE-2023-52674, CVE-2023-52675, CVE-2023-52676, CVE-2023-52677,   CVE-2023-52678, CVE-2023-52679, CVE-2023-52680, CVE-2023-52681,   CVE-2023-52682, CVE-2023-52683, CVE-2023-52685, CVE-2023-52686,   CVE-2023-52687, CVE-2023-52690, CVE-2023-52691, CVE-2023-52692,   CVE-2023-52693, CVE-2023-52694, CVE-2023-52696, CVE-2023-52697,   CVE-2023-52698, CVE-2023-6356, CVE-2023-6535, CVE-2023-6536,   CVE-2024-23849, CVE-2024-24860, CVE-2024-26582, CVE-2024-26583,   CVE-2024-26584, CVE-2024-26585, CVE-2024-26586, CVE-2024-26592,   CVE-2024-26594, CVE-2024-26595, CVE-2024-26598, CVE-2024-26607,   CVE-2024-26608, CVE-2024-26610, CVE-2024-26612, CVE-2024-26615,   CVE-2024-26616, CVE-2024-26618, CVE-2024-26620, CVE-2024-26623,   CVE-2024-26625, CVE-2024-26627, CVE-2024-26629, CVE-2024-26631,   CVE-2024-26632, CVE-2024-26633, CVE-2024-26634, CVE-2024-26636,   CVE-2024-26638, CVE-2024-26640, CVE-2024-26641, CVE-2024-26644,   CVE-2024-26645, CVE-2024-26646, CVE-2024-26647, CVE-2024-26649,   CVE-2024-26668, CVE-2024-26669, CVE-2024-26670, CVE-2024-26671,   CVE-2024-26673, CVE-2024-26808, CVE-2024-35835, CVE-2024-35837,   CVE-2024-35838, CVE-2024-35839, CVE-2024-35840, CVE-2024-35841,   CVE-2024-35842Package Information:   https://launchpad.net/ubuntu/+source/linux-oracle-6.5/6.5.0-1024.24~22.04.1

Ubuntu Security Notice USN-6819-4

The heightened regulatory and legal pressure on software-producing organizations to secure their supply chains and ensure the integrity of their software should come as no surprise. In the last several years, the software supply chain has become an increasingly attractive target for attackers who see opportunities to force-multiply their attacks by orders of magnitude. For example, look no

The heightened regulatory and legal pressure on software-producing organizations to secure their supply chains and ensure the integrity of their software should come as no surprise. In the last several years, the software supply chain has become an increasingly attractive target for attackers who see opportunities to force-multiply their attacks by orders of magnitude. For example, look no further than 2021's Log4j breach, where Log4j (an open-source logging framework maintained by Apache and used in a myriad of different applications) was the root of exploits that put thousands of systems at risk.

Log4j's communication functionality was vulnerable and thus provided an opening for an attacker to inject malicious code into the logs which could then be executed on the system. After its discovery, security researchers saw millions of attempted exploits, many of which turned into successful denial-of-service (DoS) attacks. According to some of the latest research by Gartner, close to half of enterprise organizations will have been the target of a software supply chain attack by 2025.

But what is the software supply chain? Well for starters, it's defined as the sum total of all the code, people, systems, and processes that contribute to the development and delivery of software artifacts, both inside and outside of an organization. And what makes securing the software supply chain so challenging is the complex and highly-distributed nature of developing modern applications. Organizations employ global teams of developers who rely on an unprecedented number of open source dependencies, along with a breadth of code repos and artifact registries, CI/CD pipelines, and infrastructure resources used for building and deploying their applications.

And while security and compliance are consistently a top concern for enterprise organizations, the challenge of securing the organization's software supply chains looms larger and larger. Many organizations are making material progress with operationalizing DevSecOps practices, however, a great deal of them still find themselves in the early stages of figuring out what to do.

Which is exactly why we've put this article together. Though the following is by no means an exhaustive list, here are four guiding principles for getting your software supply chain security efforts rolling in the right direction.

****Consider All Aspects of your Software Supply Chain When Applying Security****

Given that over 80% of code bases have at least one open-source vulnerability, it stands to reason that OSS dependencies have been a central focus of software supply chain security. However, modern software supply chains encompass other entities whose security postures are either overlooked or not understood broadly enough within the organization to be properly managed. These entities are code repositories, CI and CD pipelines, infrastructure, and artifact registries, each of which requires security controls and regular compliance assessment.

Frameworks such as OWASP Top-10 for CI/CD and CIS Software Supply Chain Security Benchmark. Adhering to these frameworks will require granular RBAC, applying the principle of least privilege, scanning containers and infrastructure-as-code for vulnerabilities and misconfigurations, isolating builds, integrating application security testing, and proper management of secrets – just to name a few.

****SBOMs are Essential for Remediating Zero-days and Other Component Issues****

Part of Executive Order 14028, issued by the White House in mid-2021 to strengthen the nation's cybersecurity posture, mandates that software producers provide their federal customers with a software bill of materials (SBOMs). SBOMs are essentially formal records intended to provide visibility into all the components that make up a piece of software. They provide a detailed, machine-readable inventory that lists all open source and third-party libraries, dependencies, and components used in building the software.

Whether an organization is compelled by EO 14028 or not, generating and managing SBOMs for software artifacts is a valuable practice. SBOMs are an indispensable tool for remediating component issues or zero-day vulnerabilities. When stored in a searchable repository, SBOMs provide a map of where a specific dependency exists and enable security teams to quickly trace vulnerabilities back to impacted components.

****Govern the Software Development Lifecycle with Policy-as-code****

In the world of modern application development, rock-solid guardrails are an essential tool for eliminating errors and intentional actions that compromise security and compliance. Proper governance throughout the software supply chain means that the organization has made it easy to do the right things and extremely difficult to do the wrong things.

While many platforms and tools offer out-of-the-box policies that can be quickly enforced, policy-as-code based on the Open Policy Agent industry standard enables authoring and enforcing fully-customizable policies. Policies governing everything from access privileges to allowing or denying the use of OSS dependencies based on criteria such as supplier, version, package URL, and license.

****Be able to Verify & Ensure Trust in your Software Artifacts using SLSA****

How can users and consumers know that a piece of software is trustworthy? In determining the trustworthiness of a software artifact, you'd want to know about things like who wrote the code, who built it, and on which development platform it was built. Knowing what components are in it would also be something you should know.

Making a decision whether to trust software is possible once provenance– the record of a software's origins and chain of custody– can be verified. For this, the Supply Chain Levels for Software Artifacts (SLSA) framework was created. It gives software-producing organizations the ability to capture information about any aspect of the software supply chain, verify properties of artifacts and their build, and reduce the risk of security issues. In practice, it's essential for software-producing organizations to adopt and adhere to the SLSA framework requirements and implement a means of verifying and generating software attestations which are authenticated statements (metadata) about software artifacts throughout their software supply chains.

Given the magnitude and complexity of securing the modern software supply chain, the above guidance merely scratches the surface. But like everything else in the world of building and deploying modern applications, the practice is evolving fast. To help you get started, we recommend reading _How to Securely Deliver Software –_ an ebook full of best practices designed to strengthen your security posture and minimize risk for your business.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Practical Guidance For Securing Your Software Supply Chain

For a while, the botnet spread but did essentially nothing. All the malicious payloads came well after.

Source: Phil Degginger via Alamy Stock Photo

A previously harmless Linux botnet has been updated to include a suite of malicious and exploitative components.

The unimaginatively named "P2PInfect" is a worm that leverages the Redis in-memory database application to spread across networks in a peer-to-peer, worm-like manner, creating a botnet along the way. By the time it was first discovered about a year ago, it had yet to cause anyone any real damage — a fact which it used to stealthy effect, by creating very little ruckus in newly infected networks.

This is not the case anymore. According to Cado Security, an update has been propagated across P2PInfect infections globally which includes a brand new rootkit, cryptominer, and even ransomware.

"Last year we were sitting there, scratching our heads, going: 'Why?,'" Al Carchrie, R&D lead solutions engineer at Cado Security, recalls about seeing the innocuous botnet for the first time. "It wasn't until the last couple of weeks that we saw there had been changes — it seems to have grown arms and legs."

**How PRPInfect Started**

On first impression, researchers observed a few things about P2PInfect that they could explain, and a few they couldn't.

First, the known: P2PInfect targeted misconfigured Redis-integrated servers accessible from the Internet. With such an inroad into a network, the malware took advantage of Redis' leader-follower topology, in which a designated "leader" node handles the primary copy of some data, and spreads exact copies to a network of follower nodes. The program used this mechanism to spread itself between Redis nodes across networks.

This seemed to be a good way to establish command-and-control (C2) and potentially spread second-stage malware. At the time, though, this quasi botnet wasn't being used for much at all.

Researchers did note, though, that the word "miner" popped up in P2PInfect's code — a potential indication of what was to come, perhaps, but nothing more.

"Our best estimate was that they were trying to do an initial spread as a botnet, probably to get a significant mass, so that when their plan came into action, it would then be more effective because they'll have a significant number of hosts," Carchrie says.

That prediction has now come to fruition.

**How P2PInfect Is Going**

P2PInfect has been updated with a usermode rootkit, and its "miner" binary has been activated. In the time since, the malware has leveraged its victims to mine around 71 Monero coins, equivalent to around £10,000.

Interesting, too, is a new ransomware component targeting a variety of file types including .xls, .py, .sql, and more. Though scary in theory, this aspect of P2PInfect seems to have been thought through the least.

For one thing, the ransomware looks for specific file extensions, but Linux does not necessarily require that files have extensions to begin with.

More to the point: Redis doesn't save any data to disk by default—its whole value proposition surrounds storage in-memory. It can be configured to save data to files, but the extension for these files—.rdb—is not among those sought by the ransomware. "With that in mind," Cado wrote, "it's unclear what the ransomware is actually designed to ransom."

**What to Do**

From Carchrie's vantage point, P2PInfect infections appear to be most concentrated in East Asia.

Redis is commonly used in businesses across the globe, though. Its open source version has more than four billion Docker pulls, and nearly 10,000 organizations use its Enterprise product, including British Airways and MGM Resorts.

So, he warns, organizations have to watch that their servers are properly protected from outside threats — only exposed to trusted users, behind firewalls, properly configured, etc.

And while it's not so easy to spot totally dormant malware, now that P2PInfect is revved up, it should be leaving behind plenty of easily detectable artifacts. "The cryptomining is going to drain as much CPU as possible, and the ransomware will go after files on disks, so disk utilization then starts to spike as well. You'll be looking for indications of those," he says.

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Tag

#perl