I18next — CraftedSignal Threat Feed

i18next-http-middleware Prototype Pollution and Path Traversal Vulnerability

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

i18next-http-middleware versions prior to 3.9.3 are susceptible to prototype pollution, path traversal, and SSRF attacks. The vulnerability stems from the insufficient validation of the lng (language) and ns (namespace) parameters passed via HTTP requests to the getResourcesHandler and the missingKeyHandler. These handlers, intended to serve localization resources, expose attack surface because they process user-controlled input without proper sanitization. This allows attackers to manipulate object properties, access unintended files or internal services, and cause denial-of-service conditions. The vulnerability was discovered via an internal security audit. Defenders should upgrade to version 3.9.3 to remediate the risks.

Attack Chain

The attacker crafts an HTTP GET request to the /locales/resources.json endpoint, targeting the getResourcesHandler.
The request includes malicious lng and ns query parameters, such as lng=__proto__&ns=isAdmin, or ns=../../etc/passwd.
The getResourcesHandler extracts the lng and ns parameters without sufficient validation.
The lng and ns values are passed to utils.setPath(resources, [lng, ns], ...) which allows writing to the Object prototype if lng is __proto__.
The lng and ns values are passed to i18next.services.backendConnector.load(languages, namespaces, ...) to load resource bundles. With filesystem or HTTP backends, this can enable path traversal or SSRF if ns or lng contain malicious path segments.
Alternatively, the attacker sends a POST request with a body containing a malicious __proto__ key to missingKeyHandler, for example {"__proto__": {"isAdmin": true}}.
The missingKeyHandler iterates over the request body using for...in, including inherited prototype properties, and forwards the malicious data into saveMissing.
Successful exploitation leads to prototype pollution, arbitrary file access, SSRF, or denial of service.

Impact

Successful exploitation can have significant consequences. Prototype pollution allows attackers to manipulate object properties globally, leading to broken authorization checks (e.g., bypassing if (user.isAdmin)), type confusion errors, or potentially remote code execution. Path traversal enables access to sensitive files on the server, like configuration files or password databases, while SSRF allows attackers to interact with internal services. Finally, the unbounded growth of the i18next.options.ns list and repeated backend load calls can lead to denial of service due to memory and CPU exhaustion. This can impact availability of the service and potentially other services on the same host.

Recommendation

Upgrade to i18next-http-middleware version 3.9.3 or later to address the vulnerabilities.
Deploy the Sigma rules provided below to detect exploitation attempts targeting the getResourcesHandler and missingKeyHandler endpoints.
If upgrading is not immediately feasible, implement a WAF rule as a partial mitigation to block requests containing __proto__, constructor, prototype, .., or control characters in lng/ns query parameters or body keys as suggested in the advisory.

i18next-fs-backend Path Traversal Vulnerability

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

The i18next-fs-backend library, a file system backend for the i18next internationalization framework, is vulnerable to a path traversal attack in versions prior to 2.6.4. This vulnerability arises from the unsanitized use of the lng (language) and ns (namespace) parameters when constructing file paths for loading and writing locale files. If an application exposes the language code to user input, an attacker can craft a malicious lng or ns value containing directory traversal sequences (e.g., ../) to escape the intended locale directory. Successful exploitation can lead to arbitrary file read, arbitrary file overwrite, and, if .js or .ts files are used for localization, arbitrary code execution. This vulnerability highlights the importance of input validation, especially when constructing file paths from user-controlled data. The vulnerability was patched in version 2.6.4.

Attack Chain

An attacker identifies an application using a vulnerable version of i18next-fs-backend (versions prior to 2.6.4) and exposes the language code to user input via query parameters (e.g., ?lng=), cookies, or request headers.
The attacker crafts a malicious lng value containing directory traversal sequences, such as ../../../../etc, to target sensitive files outside the intended locale directory.
The attacker sends a request to the application with the crafted lng parameter.
The application passes the unsanitized lng value to the i18next.t() function.
The i18next-fs-backend library interpolates the malicious lng value into the loadPath configuration option, without proper validation. For example, loadPath: '/locales/{{lng}}/{{ns}}.json' becomes /locales/../../../../etc/{{ns}}.json.
The backend attempts to read the file specified by the crafted path (e.g., /etc/passwd).
If successful, the contents of the targeted file are returned as a translation resource, potentially exposing sensitive information. If the attacker crafted the lng or ns value to point to a .js or .ts file containing malicious code, the backend will execute the file using eval(), leading to arbitrary code execution on the server.
Alternatively, if the application attempts to write a missing translation key using the crafted path (via addPath), the attacker could overwrite arbitrary files on the system, potentially leading to application compromise.

Impact

Successful exploitation of this vulnerability can have severe consequences. Arbitrary file read allows attackers to access sensitive data, such as configuration files, database credentials, or application source code. Arbitrary file overwrite can lead to application malfunction or complete compromise. If the application uses .js or .ts files for localization and the attacker is able to inject malicious code into those files through path traversal, arbitrary code execution can result, potentially allowing the attacker to gain full control of the server. The number of victims depends on the popularity and configuration of applications using the vulnerable i18next-fs-backend library.

Recommendation

Upgrade to i18next-fs-backend version 2.6.4 or later to patch the path traversal vulnerability as this version introduces the isSafePathSegment and interpolatePath functions to sanitize the path.
If upgrading is not immediately feasible, sanitize the lng and ns values at the application boundary before passing them to i18next. Reject values containing .., /, \, control characters, and limit the length to prevent path traversal as mentioned in the advisory.
If using .js or .ts locale files, carefully review them for any suspicious or unexpected code. The advisory highlights that these files must be treated as trusted code.
Monitor web server logs for suspicious requests containing directory traversal sequences in the lng or ns parameters. Deploy the first Sigma rule for this purpose.

i18next-http-middleware HTTP Response Splitting and DoS Vulnerability

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

The i18next-http-middleware library, in versions prior to 3.9.3, exhibits a vulnerability stemming from insufficient sanitization of user-controlled language values. These values are written into the Content-Language HTTP response header. The utils.escape() function, employed for sanitization, performs HTML-entity encoding but fails to strip critical characters like carriage return and line feed. When the application uses an older i18next (< 19.5.0) or produces raw detected values, CRLF sequences within the lng parameter reach res.setHeader('Content-Language', ...) without proper escaping. This flaw can result in HTTP response splitting (Node.js < 14.6.0) or a denial-of-service condition (Node.js >= 14.6.0), impacting all concurrent users of the affected process. The same vulnerability is triggered multiple times per request. This issue is resolved in version 3.9.3.

Attack Chain

The attacker crafts a malicious HTTP request targeting an application using a vulnerable version of i18next-http-middleware. The request includes a lng parameter with a payload containing CRLF sequences (e.g., %0d%0a).
The i18next-http-middleware receives the request and extracts the language value from the lng parameter.
The extracted language value is passed through utils.escape(), which performs HTML-entity encoding but does not remove CRLF sequences.
The middleware attempts to set the Content-Language header using res.setHeader(), incorporating the unsanitized language value.
If the Node.js version is less than 14.6.0, the res.setHeader() function processes the CRLF sequences, resulting in HTTP response splitting. This allows the attacker to inject arbitrary headers and control parts of the response body.
If the Node.js version is 14.6.0 or greater, res.setHeader() throws an ERR_INVALID_CHAR error because the value contains CRLF sequences.
The middleware fails to catch this error, and the exception propagates, leading to an unhandled exception.
The unhandled exception causes the Node.js process to terminate or become unresponsive, resulting in a denial-of-service condition for all concurrent users sharing that process.

Impact

Successful exploitation allows attackers to inject arbitrary HTTP headers, leading to session fixation, cache poisoning, or reflected XSS attacks. In Node.js versions 14.6.0 and later, exploitation leads to a denial-of-service condition, potentially impacting all users of an application instance. This can result in significant disruption of service availability and potential data compromise. The number of affected applications is unknown, but any application using a vulnerable version of i18next-http-middleware is at risk.

Recommendation

Upgrade i18next-http-middleware to version 3.9.3 or later to address the vulnerability by patching the utils.sanitizeHeaderValue() function, as described in the advisory.
Deploy the Sigma rule Detect i18next-http-middleware CRLF Injection Attempt to monitor for exploitation attempts by detecting suspicious URL-encoded characters in HTTP requests.
Implement a Web Application Firewall (WAF) rule to reject requests containing \r or \n characters in query parameters, cookies, and path segments as a partial mitigation, as suggested in the advisory.
Enable web server logging to ensure events related to potential exploits are captured for analysis.