chad scira

SlickStack Security Warning: SlickStack is Malware

2 months ago

A while back, I conducted a security audit on the SlickStack code base and determined that it functions as malware. While it promises streamlined server management, the implementation raises significant concerns about intentional design choices that could compromise user systems.

The Core Issue: Remote Code Execution

At the heart of the controversy is SlickStack's cron setup. Every 3 hours and 47 minutes, the software executes scripts that download files directly from a remote server using wget with the --no-check-certificate flag. This approach bypasses SSL verification, effectively exposing servers to potential man-in-the-middle (MITM) attacks. Once downloaded, these files are granted root-level permissions without any checksum validation or version control.

The justification for such frequent remote calls is unclear, as standard bash scripts typically retrieve necessary code upon installation and validate it using checksums. Updates, if needed, are generally version-controlled and validated through secure mechanisms. SlickStack’s approach, however, is "insecure by design," enabling arbitrary code execution without user awareness.

Analyzing the Code in Question

Here is the specific cron configuration that highlights the security concerns:

Breaking it Down:

• Frequency: The cron runs every 3 hours and 47 minutes.
• Remote Call: The wget command fetches scripts from the URL https://slick.fyi.
• SSL Bypass: The --no-check-certificate flag skips SSL validation, allowing potentially compromised or spoofed servers to provide files.
• No Validation: There is no checksum or signature verification to ensure the integrity of the downloaded scripts.
• Root Permissions: The downloaded files are saved in system-level directories with root access.

Additional Cron Permissions Management

Another concerning aspect of the cron setup is the management of file ownership and permissions. Here is the relevant cron configuration:

Breaking it Down:

• File Ownership: The chown root:root command ensures that all files matching *cron* in the specified directories are owned by the root user and group. This action, while standard for securing critical files, raises red flags when combined with the frequent execution of remote, unverified scripts.
• Permissions Restriction: The chmod 0700 command sets the file permissions to read, write, and execute only by the file owner (root). This restricts access to the scripts, but it does not mitigate the risk posed by downloading and executing potentially malicious or compromised files.
• Frequency: These commands are run every 3 hours and 47 minutes, further emphasizing the systemic nature of SlickStack’s design to manage these files in a manner that could facilitate exploitation.

Jesse Jacob Nickles: A Questionable Maintainer

The sole contributor to SlickStack, Jesse Jacob Nickles, has faced criticism for dubious practices surrounding the project. Allegations include purchasing stars on the project’s GitHub repository to artificially inflate its popularity and tricking clients into installing what many now view as malware on their systems. These actions have severely damaged trust in the project and its maintainer.

Furthermore, tools like SlickStack should ideally function as a set of fixed installation scripts, with updates being opt-in to ensure user control. Instead, the design of SlickStack behaves like a persistent remote code execution exploit, with deliberate efforts made to bypass standard security protocols. This not only jeopardizes the user’s system but also opens websites to third-party attacks.

Intentional Redirects and MITM Vulnerability

Initially, SlickStack utilized GitHub’s CDN to retrieve files directly. However, the maintainer later introduced a redirect, funneling requests through a personal server before reaching the intended destination. This change not only increases the risk of MITM attacks but also questions the integrity of the maintainer’s intentions. Furthermore, this inconsistency stands out as other requests within the project still use GitHub’s CDN directly.

A Pattern of Suspicious Behavior

Attempts to report these issues have been met with resistance. Users have noted that the maintainer deletes forum topics highlighting security concerns and blocks individuals on platforms like GitHub. This lack of transparency further diminishes trust in the project.

The Bigger Picture: Trust and Transparency

Open-source projects thrive on trust and community contributions. However, SlickStack’s design choices coupled with its maintainer’s behavior undermine the very principles of open-source development. Any project built around insecure remote execution as a fundamental core block should come with a massive warning label. No one should touch such a project if they value their data.

By allowing root-level remote code execution, introducing unnecessary redirects, and dismissing valid concerns, SlickStack has positioned itself as a liability rather than a solution. The very architecture of this software opens users’ systems to exploitation not only by its maintainer but also by potential third-party attackers.

A Safer Alternative: WordOps

In response to these vulnerabilities, some users have forked SlickStack to remove the insecure elements, such as remote server calls. Additionally, WordOps has emerged as a viable alternative, offering a similar feature set without the security risks inherent in SlickStack’s design. After a thorough review of WordOps’ source code, users report no significant issues, making it a more reliable choice for WordPress users.

Why?

For WordPress users prioritizing security and reliability, the concerns surrounding SlickStack cannot be ignored. While the software may offer convenience, its current implementation leaves servers vulnerable to exploitation. Alternatives like WordOps provide a safer path forward, adhering to best practices and fostering trust within the community.

If you are currently using SlickStack, consider reviewing your setup and exploring alternatives to ensure the integrity of your WordPress installations.

Update: Jan 21, 2025

Jesse Jacob Nickles has made numerous edits to the cron files, committing them one at a time. As a result, these updates are syncing in real-time with all the SlickStack servers. On a positive note, some --no-check-certificate calls have been removed.

However, the codebase still contains the original MITM RCE issue linked to their personal domain, along with inconsistent domain usage throughout the project. Additionally, there is no straightforward method to uninstall the project.

Given that the critical root-level remote code execution issue remains unresolved and the blind permission escalation vulnerability persists, I strongly advise against using this project.