A flaw was found in moodle. The cURL wrapper in Moodle strips HTTPAUTH and USERPWD headers during emulated redirects, but retains other original request headers, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-7wmp-2xmx-g6h8: Moodle authorization headers preserved between "emulated redirects"

A flaw was found in moodle. Some hidden user profile fields are visible in gradebook reports, which could result in users without the "view hidden user fields" capability having access to the information.

GHSA-c767-4whh-v7rw: Moodle has user information visibility control issues in gradebook reports

A flaw was found in moodle. Insufficient capability checks make it possible for users with access to restore glossaries in courses to restore them into the global site glossary.

GHSA-4gq2-x5w4-7hp8: Moodle has insufficient capability checks

A flaw was found in moodle. Matrix room membership and power levels are incorrectly applied and revoked for suspended Moodle users.

GHSA-q99x-mjmh-v8w7: Moodle's user/power level management inconsistent with suspended users

A flaw was found in moodle. External API access to Quiz can override contained insufficient access control.

GHSA-jpf2-9ppp-2c49: Moodle has insufficient access control

Companies and organizations need to recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively.

Source: Yury Zap via Alamy Stock Photo

COMMENTARY

Open source security incidents aren't going away. The reliance on open source software (OSS) increases year-over-year, with more than 95% of all software, including open source, in some capacity. From operating systems to critical libraries to Web applications and more, open source software (OSS) plays a pivotal role in the current technology landscape. However, this widespread reliance introduces significant security risks. As the use of OSS continues to evolve, so does the importance of securing it. This responsibility falls not on individual hobbyist developers, but on the companies and organizations that have the resources to dedicate engineers specifically to open source security. These organizations are the ones that benefit the most from open source and should be the ones who contribute the most back.  

**Essential Skills for Open Source Security Developers**

Securing open source is similar to securing closed source, but many of the skills required are of higher importance for open source, due to various factors. Open source is public and tends to have broader adoption than much closed source software. A closed source tool with a security vulnerability used by a handful of customers is going to have a very different impact than something like OpenSSH having a vulnerability, given its use on millions of servers worldwide. 

I hope this doesn't come as a surprise, but the most important open source skills to have are soft skills. Most software development time is spent doing things other than actually writing code. Here are a few key skills:  

*   Public collaboration: Open source projects are inherently collaborative and involve contributors from around the globe. Effective communication ensures that security practices are understood and implemented correctly. 
    

*   Preventing miscommunication: Many security bugs arise from misunderstandings. Clear documentation and open dialogues can prevent these issues from occurring. 
    

*   Proactive approach: Keeping security at the forefront of daily tasks helps in early detection of potential vulnerabilities. 
    

*   Continuous vigilance: A security-first mindset encourages constant evaluation of code for potential risks. 
    

*   Responsibility: Treating open source projects with the same seriousness as closed source commercial projects ensures higher security standards. 
    

*   Accountability: Developers who feel a sense of ownership are more likely to produce secure and reliable code. 
    

Just because soft skills are more important than hard skills for software development doesn't mean those hard skills are irrelevant. They are still important, and a few of them in particular are of focused importance for open source security. The open source community gets the benefit of a project being public, enabling the community to come together to secure the project with experts in different areas providing their expertise. However, with open source being public, it also exposes projects to malicious actors, like we saw in the XZ compromise, where a bad actor maintainer contributed innocuous-looking, but ultimately malicious, code. This is why software engineers focused on open source security need to be vigilant and experienced to know what to look for when they get contributions from anonymous developers. Here are some of the skills that are important: 

1.  Security Engineering and Threat Modeling 
    

*   Understanding attack vectors: Knowledge of how vulnerabilities are exploited is crucial. 
    

*   Techniques like STRIDE: Familiarity with threat modeling methodologies helps in identifying and mitigating risks. 
    

*   Common vulnerabilities: Awareness of issues like SQL injection, cross-site scripting (XSS), and buffer overflows is essential. 
    

*   Language-specific vulnerabilities: Each programming language has its own set of security concerns. This is especially important for languages and ecosystems that don't have built-in memory safety mechanisms. 
    

*   Ecosystem proficiency: Knowledge of the packaging ecosystem like PyPI, npm, etc., and how software is developed in that ecosystem is important to understand external risks to the project like upstream dependencies. You can write perfectly safe code and include a vulnerable or malicious dependency and ship insecure software. Knowing when to include a dependency and when it's better to write the functionality yourself is very important as well. 
    

*   Build pipelines: Incorporating security checks into continuous integration and deployment processes ensures ongoing security. Open source developers wear multiple hats and need to understand and secure the continuous integration flow. The artificial intelligence (AI) analog would be the training pipeline. 
    

*   Contextual awareness: Understanding how software will be used by consumers helps in identifying potential security flaws. 
    

*   Automated testing: Implementing tools that automatically scan for vulnerabilities can catch issues early. 
    

*   Comprehensive test coverage: Ensuring that all parts of the code are tested reduces the risk of overlooked vulnerabilities. 
    

As the reliance on open source software continues to grow, so does the necessity for open source developers focused on security. This need is becoming even more critical with the rise of open source AI projects. Open source AI introduces new layers of complexity and opacity due to massive datasets and the probabilistic nature of trained models. The sheer volume of data and the intricacies of machine learning algorithms make it challenging to identify vulnerabilities and predict how models might behave in unforeseen circumstances. 

The "black box" aspect of AI models means that even the developers may not fully understand how inputs are being processed to produce outputs. This opacity can be exploited, leading to security breaches such as data poisoning, adversarial attacks, and unintended bias. Therefore, securing open source AI requires specialized skills and a deep understanding of both AI technologies and security principles. 

Companies and organizations must recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively, especially in the rapidly evolving field of AI. By fostering these skills, we can enhance the security of open source projects, benefiting individual organizations and the global community that relies on them. 

**About the Author**

Co-Founder & Chief Technology Officer, Kusari

Michael Lieberman is co-founder and chief technology officer (CTO) of Kusari, where he helps build transparency and security in the software supply chain. He has extensive engineering and architecture expertise with an emphasis on cloud-native technologies and security and privacy use cases. Prior to Kusari, he held engineering leadership positions with Citi, Mitsubishi UFJ Financial Group (MUFG), and Bridgewater Associates. Michael is an active member of the open source community, co-creating the GUAC and FRSCA projects and co-leading the CNCF’s Secure Software Factory Reference Architecture white paper. He is also co-chair of the Cloud Native Computing Foundation Financial Services User Group and an OpenSSF TAC and SLSA steering committee member.

Open Source Security Incidents Aren't Going Away

A critical security vulnerability in Palo Alto Networks’ Expedition tool is being actively exploited by hackers. CISA urges…

A critical security vulnerability in Palo Alto Networks’ Expedition tool is being actively exploited by hackers. CISA urges patch – Learn how to protect your network and sensitive data by patching your Expedition software immediately.

If you have recently migrated your network configuration to Palo Alto Networks using their Expedition tool, you need to act quickly as a critical security flaw (CVE-2024-5910) in the tool is actively being exploited by threat actors. This means hackers can takeover administrator account, access sensitive configuration data, and even gain control over your firewalls if you haven’t patched your Expedition software.

For your information, Expedition is a handy tool that helps users seamlessly switch their network configuration from other vendors like Cisco or Checkpoint to their own products. It automates many steps, making the transition smoother for businesses. The tool will be will discontinued from January 2025.

Palo Alto Networks has reportedly been notified by the Cybersecurity and Infrastructure Security Agency (CISA) about the exploitation of a security flaw within its Expedition tool versions prior to 1.2.92. Palo Alto already released a patch for this vulnerability in July, but attackers are already exploiting it.

 “Palo Alto Expedition contains a missing authentication vulnerability that allows an attacker with network access to takeover an Expedition admin account and potentially access configuration secrets, credentials, and other data,” CISA explained in its advisory.

The advisory warns that configuration secrets, credentials, and other data moved into Expedition are at risk due to the critical flaw as the tool can trigger an administrative account takeover for threat actors. This vulnerability is rated as “critical” with a CVSS score of 9.3 (out of 10) entails a missing authentication for Critical Function (CWE-306). This means it’s very easy for attackers to exploit and can have severe consequences.

Exploitation attempts likely rose in October when a security researcher Zach Hanley released a proof-of-concept (PoC) exploit. It demonstrates how to combine CVE-2024-5910 and another vulnerability (CVE-2024-9464) to execute unauthenticated remote code on vulnerable Expedition servers, allowing attackers to reset admin accounts and control firewall configurations.

CISA has added this vulnerability to its “Known Exploited Vulnerabilities” catalog, urging federal agencies to address it before November 28th.

To protect yourself, update your software to the latest version (1.2.92 or later). Once updated, change usernames, passwords, and API keys for both Expedition and firewalls processed through Expedition.  Additionally, sign up for security alerts from Palo Alto Networks or other reputable sources to stay updated on the latest threats and vulnerabilities.

It is worth noting that the advisory comes after Threat intelligence firm Volexity discovered a zero-day exploit in April that affected Palo Alto Networks’ firewall appliances. The vulnerability had a maximum CVSS score of 10 and probably exploited by nation-state hackers, according to researchers.

John Bambenek, President at Bambenek Consulting weighed in on the situation stating, _“_This vulnerability lets attackers reach out and take over these devices without authentication and they are the kind of tool you set up for a tactical reason. Once the work is done, you forget about it. If, for whatever reason, you can’t shut it down, get these devices off the open Internet._“_

1.  Palo Alto Patches 0-Day Exploited by Python Backdoor
2.  CISA and Fortinet Warns of New FortiOS Zero-Day Flaws
3.  Hackers Target Check Point VPNs, Security Fix Released
4.  Private details of Palo Alto Networks employees leaked online
5.  Cisco Fixes High-Severity Code Execution, VPN Hijacking Flaws

CISA Urges Patching of Critical Palo Alto Networks’ Expedition Tool Vulnerability

Cybersecurity researchers have uncovered nearly two dozen security flaws spanning 15 different machine learning (ML) related open-source projects.
These comprise vulnerabilities discovered both on the server- and client-side, software supply chain security firm JFrog said in an analysis published last week.
The server-side weaknesses "allow attackers to hijack important servers in the

Security Flaws in Popular ML Toolkits Enable Server Hijacks, Privilege Escalation

Hewlett Packard Enterprise (HPE) has released security updates to address multiple vulnerabilities impacting Aruba Networking Access Point products, including two critical bugs that could result in unauthenticated command execution.
The flaws affect Access Points running Instant AOS-8 and AOS-10 -

AOS-10.4.x.x: 10.4.1.4 and below
Instant AOS-8.12.x.x: 8.12.0.2 and below
Instant AOS-8.10.x.x:

HPE Issues Critical Security Patches for Aruba Access Point Vulnerabilities

With cybersecurity threats continuously evolving, having a strong incident response (IR) plan is crucial for businesses of all…

With cybersecurity threats continuously evolving, having a strong incident response (IR) plan is crucial for businesses of all sizes. Effective IR not only minimizes the financial and reputational damage caused by security incidents but also ensures that organizations can return to normal operations without delay. Here’s why Incident Response is essential and what it entails.

*   **Minimizing Downtime and Financial Impact**

When a **cyber incident strikes**, the faster an organization can identify, contain, and mitigate it, the lower the financial losses. An effective IR plan enables businesses to respond efficiently, which helps reduce costly downtime, potential ransom demands, and expenses related to data recovery.

*   **Protecting Sensitive Data and Customer Trust**

In many sectors, a breach of sensitive information can damage customer trust. Effective incident response minimizes the risks of exposing sensitive and confidential data, data; a quick, efficient response reassures customers that the organization prioritizes security, which is invaluable for customer loyalty and **brand reputation**.

*   **Staying Compliant and Avoiding Legal Consequences**

Organizations today must manage a complicated set of regulatory requirements related to data protection, including prominent regulations like the General Data Protection Regulation (**GDPR**) in Europe and the Health Insurance Portability and Accountability Act (**HIPAA**) in the United States. An effective Incident Response plan is essential in helping organizations meet these obligations.

*   **Establishing Clear Protocols**

By establishing clear protocols for breach notifications, data handling, and response strategies, an IR plan ensures compliance with industry standards and legal mandates. This approach reduces the risk of facing **hefty fines**, legal penalties, and reputational damage that can arise from non-compliance. Moreover, adhering to these regulations fosters a culture of accountability and transparency within the organization, ultimately strengthening stakeholder trust and confidence in its commitment to compliance and data security.

*   **Mitigating Long-Term Operational Risks**

A strong Incident Response strategy plays a major role in minimizing long-term operational risks by identifying and augmenting system, process, and people vulnerabilities that attackers could exploit to gain sensitive, confidential, or trade secret organization.

Furthermore, if an incident has occurred, updated IR planning allows organizations to document and analyze breached data, offering valuable insights that increase defences, refine response protocols, and enhance system, process, and human strength over time.

****Key Components of an Effective Incident Response Plan****

*   **Preparation:** A successful incident response begins with thorough preparation. This includes educating employees on recognizing suspicious activities and establishing clear reporting protocols. Regular training sessions and simulations help cultivate a culture of vigilance and ensure everyone understands their role in the incident response process.
*   **Detection and Analysis:** Early detection is critical to mitigating damage. Incident response teams should leverage advanced monitoring tools and threat intelligence to identify potential incidents in time. Once detected, the team conducts a detailed analysis to assess the severity and potential impact on the organization.
*   **Containment and Eradication:** After an incident is confirmed, immediate action is necessary to contain the threat. This may involve isolating affected systems to prevent further spread and executing eradication procedures to eliminate the root cause of the incident. Effective **containment strategies** limit damage and protect unaffected systems.
*   **Recovery:** Once the threat is contained, the focus shifts to recovery. Systems must be carefully restored to normal operations, with thorough testing to ensure functionality and security. Continuous monitoring during this phase helps to identify any lingering issues or signs of re-infection.
*   **Post-Incident Analysis:** After recovering from an incident, it’s essential to conduct a comprehensive review of the response efforts. This analysis helps identify strengths and weaknesses in the incident response plan, providing valuable insights for improving future strategies. Implementing lessons learned is vital for enhancing resilience against future threats and ensuring the organization is better prepared.

****Who should be on an incident response team?****

An effective incident response team (IRT) should include members with diverse expertise to address all critical areas. Core roles often include IT and security professionals, such as network engineers, system administrators, and cybersecurity analysts, who manage technical aspects. A legal advisor is essential for compliance and regulatory guidance, while a communications specialist handles both internal and external messaging.

In conclusion, businesses face a growing array of cyber threats that can put operations, reputations, and customer trust at risk. Developing **an effective incident response (IR**) strategy is essential for mitigating these risks.

By partnering with trusted service providers, companies can ensure they are prepared to respond quickly and efficiently when incidents arise and meet all compliance obligations, including notification requirements. A well-structured IR plan helps minimize potential damage, maintain regulatory compliance, protect sensitive data, and ensure recovery without delay.

Furthermore, a proactive IR approach fosters a culture of preparedness and resilience, allowing organizations to quickly adapt and manage the rising number of cybersecurity threats. By implementing clear response protocols and maintaining transparent communication channels, businesses can safeguard their operations and reduce the long-term consequences of security breaches.

Ultimately, a comprehensive incident response plan not only supports immediate recovery but also strengthens the organization’s overall security posture, protecting its long-term interests, information assets, and business integrity.

****Resources:****

_https://www.atlassian.com/incident-management/incident-response_

_https://insights.integrity360.com/what-are-the-key-elements-of-an-effective-incident-response-strategy_

1.  **What Is Incident Management Software?**
2.  **Key Features Of Threat Intelligence Platforms**
3.  **A Step-by-Step Guide to How Threat Hunting Works**
4.  **0-day attacks are potent cyber threats and require serious response**
5.  **Small Business Owners Must Prioritize Cybersecurity to Stay Operational**

Tag

#vulnerability