Facebook
Twitter
- Server operating system version
- Plesk Obsidian 18.0.44
- Plesk version and microupdate number
- 18.0.44 Update #3
APP Check has highlighted the following:-
POSSIBLE DEPENDENCY CONFUSION
It is extremely common for applications to depend on packages from public registries such as NPM, Maven Central, Packagist, and Python Package Index. It is also common for organisations to utilise private registries to mirror the public index or distribute internal packages which cannot be published publically. To accomodate this, Package managment tools such as npm, yarn, pip, maven, or composer allow specifying multiple sources from which to download components. How package management tools resolve names across multiple registries can provide an opportunity for attackers to achieve code execution on vulnerable systems.
When resolving a dependency name to a package some package managers (notably npm and pip) will select the package with the highest version number from the configured feeds. Therefore an attacker can register the package on the public index which a high version number, and achive code execution when the package manager installs the package. This may be detectable as an unexpected failure in a build or test pipeline, however at this point the attacker's code has already executed potentially resulting in the exfiltration of any secrets or access tokens or direct attacks on the internal network.
It should also be noted that some services that merge package feeds also allow this substituation attack if packages from public sources may override those from private sources, rather than treating the private source as canonical.
-------
REMEDIATION
Guarding against Dependency Confusion attacks requires a multi-layer approach.
Reference one private registry, not multiple. Many package managers do not enforce order or priority when querying multiple feeds, for these package managers a single private registry should be configured. Note this may require pushing public packages to the private feed. Ensure the private feed is configured to prevent public packages overriding private packages.
Claim private package names on the public registry to prevent them being hijacked.
Some package managers support controlled scopes, namespaces, or prefixes which can be used with packages you control to protect against an attacker hijacking a name that you use privately, and provide confidence that any packages you release publicly are legitimate.
NPM allows you to configure a scope prefix in combination with a registry, since only the configured registry will be searched for that scope this prevents a substitution attack via the public registry. Extreme care must be taken to ensure that this configuration is implemented on all clients that use the package.json file.
Composer strictly enforces a vendor prefix in all package names, and allows a repository to be configured which is treated as canonical (preventing substitution attacks). However care must be taken to ensure the repository is configured to prevent Composer falling back to packagist.org (the default public registry) where an attacker may be able to publish a package with the vendor prefix. Note packagist.org restricts access to the vendor prefix to the first maintainer to publish a package, therefore you may wish to publish a dummy package to any vendor prefix you utilise internally to prevent exploitation in the event of misconfiguration of the composer.json file.
Since the substitution attack relies on the package manager selecting the package with the highest version, another potential mitigation is to explicitly pin the dependency version rather than specifying an open range
-------
Technical Details
The source map file accessible at **************:8443/ui-library/plesk-ui-library.min.js.map includes references to the following dependencies which an attacker may be able to hijack:
• node_modules
POSSIBLE DEPENDENCY CONFUSION
It is extremely common for applications to depend on packages from public registries such as NPM, Maven Central, Packagist, and Python Package Index. It is also common for organisations to utilise private registries to mirror the public index or distribute internal packages which cannot be published publically. To accomodate this, Package managment tools such as npm, yarn, pip, maven, or composer allow specifying multiple sources from which to download components. How package management tools resolve names across multiple registries can provide an opportunity for attackers to achieve code execution on vulnerable systems.
When resolving a dependency name to a package some package managers (notably npm and pip) will select the package with the highest version number from the configured feeds. Therefore an attacker can register the package on the public index which a high version number, and achive code execution when the package manager installs the package. This may be detectable as an unexpected failure in a build or test pipeline, however at this point the attacker's code has already executed potentially resulting in the exfiltration of any secrets or access tokens or direct attacks on the internal network.
It should also be noted that some services that merge package feeds also allow this substituation attack if packages from public sources may override those from private sources, rather than treating the private source as canonical.
-------
REMEDIATION
Guarding against Dependency Confusion attacks requires a multi-layer approach.
Reference one private registry, not multiple. Many package managers do not enforce order or priority when querying multiple feeds, for these package managers a single private registry should be configured. Note this may require pushing public packages to the private feed. Ensure the private feed is configured to prevent public packages overriding private packages.
Claim private package names on the public registry to prevent them being hijacked.
Some package managers support controlled scopes, namespaces, or prefixes which can be used with packages you control to protect against an attacker hijacking a name that you use privately, and provide confidence that any packages you release publicly are legitimate.
NPM allows you to configure a scope prefix in combination with a registry, since only the configured registry will be searched for that scope this prevents a substitution attack via the public registry. Extreme care must be taken to ensure that this configuration is implemented on all clients that use the package.json file.
Composer strictly enforces a vendor prefix in all package names, and allows a repository to be configured which is treated as canonical (preventing substitution attacks). However care must be taken to ensure the repository is configured to prevent Composer falling back to packagist.org (the default public registry) where an attacker may be able to publish a package with the vendor prefix. Note packagist.org restricts access to the vendor prefix to the first maintainer to publish a package, therefore you may wish to publish a dummy package to any vendor prefix you utilise internally to prevent exploitation in the event of misconfiguration of the composer.json file.
Since the substitution attack relies on the package manager selecting the package with the highest version, another potential mitigation is to explicitly pin the dependency version rather than specifying an open range
-------
Technical Details
The source map file accessible at **************:8443/ui-library/plesk-ui-library.min.js.map includes references to the following dependencies which an attacker may be able to hijack:
• node_modules
