Zero-Day Exploits, GitHub Actions Supply Chain Attacks, and OTP Auth Flaws

Today's Highlights

This week's top security news features a critical zero-day actively exploited in KnowledgeDeliver LMS and widespread supply chain cache poisoning targeting open-source projects via GitHub Actions. Additionally, a detailed analysis reveals an OTP rate-limit bypass technique enabling account takeovers through leaked validity signals.

KnowledgeDeliver flaw exploited as a zero-day to install web shells (r/cybersecurity)

Source: https://reddit.com/r/cybersecurity/comments/1tojdsq/knowledgedeliver_flaw_exploited_as_a_zeroday_to/

This report details the exploitation of a critical zero-day vulnerability within the KnowledgeDeliver learning management system (LMS). Attackers leveraged this previously unknown flaw to gain unauthorized access and deploy the notorious Godzilla web shell on affected servers. The use of a web shell allows attackers persistent remote control over the compromised server, enabling further malicious activities such as data exfiltration, lateral movement within the network, and establishment of command-and-control infrastructure.

The exploitation of a zero-day highlights the severe risks associated with unpatched and custom-built software solutions, especially those facing the internet. Organizations using KnowledgeDeliver LMS are urged to apply any available patches immediately or implement strong compensatory controls, such as strict network segmentation, intrusion detection systems, and continuous monitoring for suspicious activity (e.g., unexpected file writes, outbound connections from the LMS server). This incident serves as a stark reminder that robust security practices, including regular security audits and threat hunting, are crucial in defending against sophisticated attacks that bypass traditional defenses.

Comment: A live zero-day being exploited in the wild is always a critical alert. Understanding how web shells like Godzilla are deployed through such flaws is essential for blue teams to detect and remediate promptly.

GitHub Actions Cache Poisoning is eating open source (r/cybersecurity)

Source: https://reddit.com/r/cybersecurity/comments/1tohlr3/github_actions_cache_poisoning_is_eating_open/

A significant supply chain attack vector, dubbed "GitHub Actions Cache Poisoning," is reportedly impacting open-source projects. This technique exploits the caching mechanism within GitHub Actions workflows, where attackers can inject malicious code into cached dependencies. When subsequent legitimate builds retrieve these poisoned caches, the malicious code is executed, compromising the build process and potentially the resulting artifacts. This can lead to widespread compromise across downstream projects that rely on the affected open-source component, creating a ripple effect through the software supply chain.

The issue highlights a critical vulnerability in the CI/CD pipeline, specifically within how cached data integrity is handled. Developers and maintainers of open-source projects, and those consuming open-source components via GitHub Actions, must review their caching strategies. Implementing strict cache key management, verifying integrity of cached dependencies before use, and minimizing the scope of cached data are crucial mitigation steps. This attack underscores the need for robust supply chain security practices, extending beyond just source code to include build environments and dependencies.

Comment: This is a direct threat to the software supply chain through a popular CI/CD platform. Developers using GitHub Actions need to immediately audit their cache keys and workflow security to prevent silent code injection.

OTP lockout state leaked valid-code signal, enabling OLX account takeover (r/netsec)

Source: https://reddit.com/r/netsec/comments/1to9pek/otp_lockout_state_leaked_validcode_signal/

This technical write-up details a severe authentication vulnerability that led to account takeover on OLX. The core of the issue was an "OTP correctness leak" within the rate-limit state. Specifically, after a series of invalid OTP attempts, the application would trigger an account lockout. However, the system's response for a valid OTP attempt before the lockout differed from an invalid OTP attempt before the lockout, even if the lockout state was about to be triggered. This subtle difference in response—whether an HTTP status code, error message, or timing—leaked information about the OTP's validity.

An attacker could exploit this by making numerous invalid OTP attempts until the lockout threshold was almost met. Then, they would send a candidate OTP. By observing the subtle response difference (e.g., "account locked" vs. "incorrect OTP, account locked"), they could deduce if their candidate OTP was correct, even without ever fully bypassing the rate limit or completing the verification. This process could be repeated for different OTPs, effectively allowing an attacker to brute-force the OTP one digit at a time without triggering a permanent lockout. The vulnerability underscores the critical importance of consistent and generic error messages and responses in authentication flows to prevent oracle attacks and information leakage, even under rate-limiting conditions.

Comment: This is a classic 'oracle attack' on an authentication mechanism. Developers designing OTP systems must ensure error messages and lockout states don't leak any information about the validity of submitted codes, even in subtle ways.