Vikunja - CraftedSignal Threat Feed

Vikunja Unauthenticated Instance-Wide Data Breach via Link Share and IDOR

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

An unauthenticated attacker can exploit two chained vulnerabilities in Vikunja, a self-hosted to-do list application, to achieve instance-wide data exfiltration and destruction. The vulnerability lies in versions 2.2.0 and earlier. The first vulnerability involves the disclosure of link share hashes, including those with administrative privileges, via the ReadAll endpoint for link shares. The second vulnerability is a cross-project attachment IDOR (Insecure Direct Object Reference) that arises from improper permission checks in the ReadOne/GetTaskAttachment endpoint. By chaining these vulnerabilities, an attacker can escalate privileges from a read-only link share to an administrative role, enumerate all attachments across all projects, and then download or delete any attachment, regardless of project membership or access controls. This poses a significant risk to the confidentiality and integrity of data stored within Vikunja instances.

Attack Chain

Attacker obtains a URL for a public link share (e.g., via social engineering or accidental exposure).
Attacker authenticates to the Vikunja API using the read-only link share hash via POST /shares/{hash}/auth to obtain a JWT.
The attacker enumerates all link shares for the project associated with the initial share using GET /projects/{id}/shares. The API discloses all share hashes, including those with admin privileges.
The attacker authenticates using an admin-level share hash via POST /shares/{admin_hash}/auth to escalate privileges.
The attacker identifies an accessible task ID within the project using GET /projects/{id}/tasks. This task is only used to bypass initial checks.
The attacker exploits the attachment IDOR by sending requests like GET /tasks/{accessible_task}/attachments/{1..N} to enumerate attachment IDs sequentially across all projects. The server checks permissions against the specified task but serves attachments based solely on the attachment ID.
The attacker downloads attachments from any project by iterating through attachment IDs.
If the attacker escalated to an admin share, they can delete attachments from other projects using DELETE /tasks/{accessible_task}/attachments/{TARGET_ATTACHMENT_ID} causing data loss.

Impact

Successful exploitation of these vulnerabilities leads to a complete breach of data confidentiality and integrity. An attacker, starting with just a publicly shared link, can download every file attachment across all projects, potentially exposing sensitive documents, images, and other confidential information. The vulnerability allows for the deletion of arbitrary attachments, leading to significant data loss. The impact is amplified by the minimal attack prerequisites and the wide blast radius, affecting all projects and users within the Vikunja instance. Given that link shares are designed for external collaboration, a single leaked link can compromise the entire Vikunja instance.

Recommendation

Apply the recommended fixes as outlined in the advisory (https://github.com/advisories/GHSA-2pv8-4c52-mf8j). Specifically, ensure that the Hash field is cleared in ReadAll responses for link shares.
Implement the suggested fix for the attachment IDOR by verifying task ownership in the ReadOne method within pkg/models/task_attachment.go.
Deploy the Sigma rule to detect suspicious attachment downloads across projects based on sequential attachment ID enumeration.
Deploy the Sigma rule to detect link share enumeration, as this is the initial step in the attack chain.
Monitor web server logs for unusual patterns of API requests, particularly to the /projects/{id}/shares and /tasks/{accessible_task}/attachments/{1..N} endpoints.

Vikunja TOTP Two-Factor Authentication Bypass via OIDC Login

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Vikunja, a self-hostable to-do list application, is vulnerable to a two-factor authentication bypass (CVE-2026-34727) affecting versions 2.2.2 and earlier. The vulnerability arises in the OIDC (OpenID Connect) login flow when the EmailFallback option is enabled. If a local user has TOTP (Time-Based One-Time Password) enabled and their email address matches a user authenticating through the OIDC provider, the TOTP check is skipped. This allows an attacker who can authenticate to the OIDC provider with a matching email address to bypass the TOTP requirement and gain unauthorized access to the Vikunja account. This issue stems from the OIDC callback handler (pkg/modules/auth/openid/openid.go) issuing a JWT without verifying TOTP status.

Attack Chain

The attacker identifies a Vikunja instance with OIDC enabled and EmailFallback set to true.
The attacker identifies a valid local user with TOTP enabled and determines the user's email address.
The attacker creates or compromises an account on the configured OIDC provider that uses the same email address as the target Vikunja user.
The attacker initiates the OIDC login flow to the Vikunja instance.
The OIDC provider authenticates the attacker using their compromised or created account.
Vikunja's OIDC callback handler (pkg/modules/auth/openid/openid.go) matches the email address from the OIDC provider to the local user.
The callback handler incorrectly issues a JWT without performing TOTP verification, bypassing the second factor.
The attacker uses the received JWT to authenticate to the Vikunja API and gains full access to the user's account.

Impact

Successful exploitation allows an attacker to bypass TOTP two-factor authentication and gain unauthorized access to Vikunja accounts. This can lead to data breaches, modification of tasks and projects, and potential further compromise of the Vikunja instance. Any user who has enrolled TOTP on their local account can have that protection completely bypassed if their email address is also present in the OIDC provider. This undermines the security of TOTP enrollment.

Recommendation

Apply the recommended fix by adding a TOTP check in the OIDC callback before issuing the JWT, as described in the advisory.
Disable the EmailFallback option in the Vikunja OIDC configuration until the patch is applied.
Monitor Vikunja logs for unusual OIDC login activity, specifically successful OIDC logins for users who also have local accounts with TOTP enabled.
Deploy the Sigma rule Detect Vikunja Successful OIDC Login Bypassing TOTP to identify successful logins that bypass TOTP.
Deploy the Sigma rule Detect Vikunja OIDC Callback Request to identify potential OIDC login attempts.

Vikunja Link Share Hash Disclosure Leads to Privilege Escalation

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Vikunja, a self-hosted to-do list application, suffers from a privilege escalation vulnerability due to improper access control in its link sharing feature. The LinkSharing.ReadAll() method allows authenticated users to list all link shares for a project, including their secret hashes. This bypasses the intended LinkSharing.CanRead() check, enabling an attacker with a read-only link share to retrieve hashes for write or admin link shares on the same project. By authenticating with these leaked hashes, an attacker can escalate to full administrative privileges. The vulnerability affects versions of Vikunja prior to 2.2.2. This issue is significant because it allows unauthenticated or low-privileged users to gain complete control over a Vikunja project without requiring valid credentials.

Attack Chain

Attacker obtains a read-only link share URL for a Vikunja project.
Attacker authenticates to the Vikunja API using the read-only link share hash via a POST request to /api/v1/shares/READ_ONLY_HASH/auth, receiving a JWT.
Attacker uses the read-only JWT to make a GET request to /api/v1/projects/PROJECT_ID/shares, listing all link shares associated with the project, including their hashes. This bypasses the intended CanRead() permission check.
The ReadAll() method returns the Hash field, which is used for authentication, for all link shares, including admin shares.
Attacker extracts the hash of an admin-level link share from the API response.
Attacker authenticates to the Vikunja API using the leaked admin link share hash via a POST request to /api/v1/shares/ADMIN_HASH/auth, receiving a new JWT with administrative privileges.
Attacker uses the admin JWT to perform administrative actions such as deleting the project via a DELETE request to /api/v1/projects/PROJECT_ID.
The attacker successfully escalates privileges and gains full control over the Vikunja project, causing disruption or data loss.

Impact

This vulnerability allows an attacker with minimal access (a read-only link share) to gain full administrative control over a Vikunja project. This can lead to data breaches, unauthorized modifications, or complete deletion of project data. The vulnerability poses a high risk, especially for projects that utilize a tiered sharing approach, where read-only shares are publicly available while admin shares are intended for internal use. Successful exploitation grants the attacker the ability to perform any action within the affected project, leading to significant disruption and potential data loss.

Recommendation

Apply the patch or upgrade to Vikunja version 2.2.2 or later to address CVE-2026-33680.
Implement the authorization check in LinkSharing.ReadAll() as described in the advisory to prevent unauthorized access to link share hashes.
Deploy the Sigma rule Vikunja_LinkShare_ReadAll_Hash_Disclosure to detect attempts to list all link shares without proper authorization using the vulnerable ReadAllWeb handler.
Monitor web server logs for unusual API calls to /api/v1/projects/*/shares (where * is the project ID) that may indicate exploitation attempts, and investigate any anomalous activity.