A flaw was found in moodle. When creating an export of site administration presets, some sensitive secrets and keys are not being excluded from the export, which could result in them unintentionally being leaked if the presets are shared with a third party.

**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-vpq5-56jj-vf2m: Moodle admin presets export tool includes some secrets that should not be exported

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.

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. External API access to Quiz can override contained insufficient access control.

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

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

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

Bitcoin Fog operator sentenced to 12.5 years for laundering $400M in crypto. The dark web’s longest-running mixer processed…

Bitcoin Fog operator sentenced to 12.5 years for laundering $400M in crypto. The dark web’s longest-running mixer processed 1.2M bitcoin tied to illegal activities over 10 years.

Roman Sterlingov, a 36-year-old dual Russian-Swedish national, has been sentenced to 12 years and six months in prison for operating Bitcoin Fog, the longest-running cryptocurrency “mixer” on the **dark web**.

****The Bitcoin Fog Operation****

Between 2011 and 2021, Sterlingov’s Bitcoin Fog processed over 1.2 million Bitcoin transactions, valued at approximately $400 million at the time of the transactions. The majority of these transactions originated from **dark web marketplaces** and were linked to illicit activities such as narcotics trafficking, computer crimes, identity theft, and child sexual abuse material.

Bitcoin Fog’s clearnet site (Screenshot: Hackread.com)

****The Investigation and Prosecution****

Sterlingov’s operation was brought to an end in March 2024, when a jury found him guilty of money laundering conspiracy, money laundering, operating an unlicensed money transmitting business, and money transmission without a license in the District of Columbia.

The investigation, led by the IRS-CI District of Columbia Cyber Crime Unit and the FBI Washington Field Office, involved collaboration with international authorities, including those from Japan, Sweden, Denmark, Romania, and the UK, as well as Europol.

In addition to his prison sentence, Sterlingov has been ordered to pay a forfeiture money judgment of $395,563,025.39 ($395.56 million) and to forfeit seized cryptocurrencies and monetary assets valued at approximately $1.76 million. He will also forfeit his interest in the Bitcoin Fog wallet, which contains approximately 1,345 Bitcoins, currently valued at over $103 million.

“Through his illicit money laundering operation, Sterlingov helped criminals launder proceeds of drug trafficking, computer crime, identity theft, and the sexual exploitation of children,” **said** Principal Deputy Assistant Attorney General Nicole M. Argentieri.

While cybercriminals and money launderers have become increasingly sophisticated at using **advanced anonymization techniques** to conceal their operations, this case also highlights law enforcement’s enhanced capability to track and prosecute cryptocurrency-based money laundering.

1.  **United States Blacklists Tornado Cash**
2.  **Feds Bust Samourai Wallet Over BTC Money Laundering**
3.  **Major Dark Web Marketplace “Nemesis Market” BUSTED**
4.  **Crypto tumbler BestMixer.io seized for money laundering**
5.  **US Seizes Bitcoin Mixer Sinbad.io Used by Lazarus Group**

Bitcoin Fog Operator Gets 12.5 Years for Longest-Running Bitcoin Laundering

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

⚠️ Imagine this: the very tools you trust to protect you online—your two-factor authentication, your car’s tech system, even your security software—turned into silent allies for hackers. Sounds like a scene from a thriller, right? Yet, in 2024, this isn’t fiction; it’s the new cyber reality. Today’s attackers have become so sophisticated that they’re using our trusted tools as secret pathways,

Latest News