Fafner [_Keyzee_]

A missing authentication flaw exists in the '/admin/crypto/group/new' endpoint. This endpoint, intended for the administrative creation of new crypto group entries, lacks protection from the application's authentication mechanism. An unauthenticated remote attacker with access to the web interface can submit requests to this endpoint to create crypto group entries without a valid session or administrative credentials. This allows unauthorized modifications to data restricted to administrators and may compromise the integrity of information processed or presented by the application.

An authorization flaw exists in the legacy database export functionality that allows unauthenticated remote users to retrieve private information. The `/export/<database>` endpoint allows the export of selected internal databases without authentication. Because the application does not consistently apply private-entity access restrictions to all exportable databases, records associated with groups, markets, and posts marked as private may be disclosed. This could lead to the exposure of private ransomware intelligence, victim information, and internal tracking data.

Inconsistent authorization checks when accessing groups, markets, and ransom notes marked as private allow an unauthenticated or unauthorized remote attacker to access restricted information. This issue affects several web views and API endpoints, potentially disclosing private group or market names, ransom-note content, and associated metadata. Specifically, the `/compare` endpoint can be queried directly with the name of a private entity to retrieve post counts, mirror totals, and uptime, even if the entity is hidden from the user interface. Additionally, ransom-note views and search results lacked consistent filtering, enabling the retrieval of notes associated with private groups.

Insufficient neutralization of user-controlled input allows for Redis glob pattern injection when values are incorporated into Redis SCAN MATCH patterns. An unauthenticated attacker can use glob metacharacters such as `*`, `?`, `[`, or `]` to broaden the scan operation. This can lead to the unauthorized enumeration of health information, mirror slugs, and uptime series for all groups and markets, including private entities. The issue affects the `/api/health/<name>` and `/api/crypto/chain/<chain>` endpoints, as well as the `delete manual torrent()` function. In the case of `delete manual torrent()`, a crafted `infohash` could potentially match torrent-health keys belonging to other torrents.

RansomLook fails to enforce the privacy status of ransomware groups and markets when distributing newly collected victim posts to external notification channels. The post-processing logic verifies if an individual post is private but fails to check the privacy configuration of the associated group or market. This allows victim information from private entities to be automatically published via Rocket.Chat, Mastodon, Bluesky, and e-mail notification channels. Additionally, the public MISP feed (Malware Information Sharing Platform) incorrectly determined privacy using the `groupinfo()` function, which only queries the group database and ignores market privacy flags. Unauthorized parties accessing these channels or the feed may obtain sensitive data, including victim names and incident information from privately monitored entities.

A path traversal issue exists in the handling of the `screen` field associated with group posts. The `GroupPost.get` API handler concatenates the `screen` value from the database directly with the application's `source/` directory and opens the path without verifying if the resolved file remains within the intended directory. Since the `screen` field is free-form and can be populated via the administrative post editor or imported from a remote instance, a malicious upstream instance can provide traversal sequences like `../config/generic.json`. When the post is retrieved, the application reads the attacker-controlled path and returns the file contents Base64-encoded in the API response. This allows an administrator controlling imported post data to read arbitrary files accessible to the process, potentially exposing configuration data, API credentials, password hashes, or other secrets. The attack does not require the malicious upstream instance to have an account on the affected system.

Insufficient resource validation in the analysis PDF generation functionality allows an authenticated attacker to embed crafted resource references using schemes such as `file://` or `http://`. Because analysis documents are converted from Markdown to HTML and passed to WeasyPrint for rendering using a default URL fetcher, these references are resolved without restrictions using the server's privileges. This can lead to arbitrary local file access, exposing sensitive configuration and credentials, or Server-Side Request Forgery (SSRF), where the server initiates unauthorized requests to localhost, internal network services, or external systems.

Sensitive operator-side scraping configuration is exposed through multiple unauthenticated API responses. Location records associated with ransomware groups and markets are returned to unauthenticated callers if the location is not marked as private. These records may contain internal fields such as `header`, which can include authentication headers, session cookies, or credentials; `init script`, which may contain logic to bypass CAPTCHA, anti-bot protections, or paywalls; and `browser`, which discloses scraping environment details. An unauthenticated remote attacker can query the affected API endpoints to obtain these values, potentially replaying authentication material against monitored services or identifying and defeating collection mechanisms.

An authorization weakness exists in the web-based configuration editor. The '/admin/config' endpoint requires an authenticated session but fails to perform explicit privilege or administrator authorization checks. This allows an authenticated low-privileged user to submit crafted configuration values that are written directly to the `config/generic.json` file. Affected functionality includes the modification of notification, LDAP, SMTP, and general application settings. Exploitation could enable an attacker to alter security-sensitive behavior, redirect integrations, modify authentication configurations, disrupt external services, or cause a denial of service. Additionally, the configuration editor handles sensitive data such as passwords, tokens, secrets, and API keys, increasing the risk associated with compromised low-privileged accounts.

A stored cross-site scripting (XSS) issue exists in the cryptocurrency wallet detail view. The application stores cryptocurrency addresses and blockchain names from external sources, such as the public crowd-sourced ransomwhe.re feed, without sufficient validation. This data is subsequently embedded into an inline JavaScript `onclick` handler. While Jinja HTML autoescaping is used, it fails to protect data inserted into a JavaScript string within an HTML attribute because the browser decodes HTML entities before interpreting the attribute as JavaScript. An attacker can provide a crafted cryptocurrency address containing quote characters and JavaScript syntax to execute arbitrary code when a user clicks the CSV export button. This may occur without an authenticated account if malicious records are introduced into an external data source, allowing the execution of scripts in the security context of the web application to expose information or perform unauthorized actions.

Weaknesses in the authentication endpoint allow an unauthenticated remote attacker to enumerate valid usernames, perform unrestricted password-guessing attacks, and potentially cause a denial of service. The login process previously verified the existence of a username before performing password hash verification, creating a timing discrepancy that allows attackers to identify valid accounts. Additionally, the '/login' endpoint lacks restrictions on the frequency of failed attempts, enabling brute-force, dictionary, password-spraying, or credential-stuffing attacks. Because the password key-derivation function consumes significant CPU time, a high volume of requests can exhaust synchronous Gunicorn workers, leading to application-wide unavailability.

The application creates its Flask session-signing key without explicitly restricting file permissions, often resulting in permissions like 0644. This allows local users with access to the home directory to read the `secret key` file. This cryptographic secret is used to sign Flask session cookies and for legacy API-key key derivation. An attacker with this key can generate valid session cookies to impersonate authenticated users, including administrators. In LDAP configurations, this is simplified as the session user loader does not verify if the username corresponds to an existing local user. Successful exploitation requires local file system access and can lead to a complete compromise of authentication and authorization controls.

The authenticated `/admin/apikeys` administration page exposes complete API keys within the HTML source. While the user interface shows only a shortened version of the key, the full token is embedded in hidden form fields used for enable/disable, private-access, and delete actions. This allows API credentials to be recovered by inspecting the page source or Document Object Model (DOM). Additionally, these credentials may be exposed through browser caches, debugging proxies, monitoring systems, or other intermediaries that inspect HTTP response bodies. An attacker with access to these tokens can authenticate with the privileges assigned to the key, potentially gaining access to private data.