Anyquery Server Mode: Unrestricted ATTACH DATABASE Enabling Arbitrary File Write and RCE

Vulnerability Description

Anyquery's server mode (anyquery server) implements a MySQL-compatible protocol layer but fails to sanitize or restrict SQL commands before forwarding them to the underlying SQLite engine. SQLite's native ATTACH DATABASE command is a legitimate disk I/O primitive designed for database mounting; however, in this context it becomes a direct file-write primitive. The vulnerability class is Unrestricted Resource Access combined with Improper Input Validation. An attacker can craft ATTACH DATABASE '/path/to/target' statements to create arbitrary files at process-writable locations on the filesystem. The root cause is the absence of command whitelisting or SQLite security pragmas that would restrict filesystem operations.

Proof-of-Concept Significance

This PoC demonstrates a pre-authentication arbitrary file write vulnerability with minimal preconditions: only network access to the Anyquery server port is required. The attack is highly reliable because SQLite's ATTACH DATABASE is deterministic and does not require special configuration. The PoC's significance lies in proving that file contents need not be valid SQLite format—attackers can inject text payloads (PHP code, shell commands, SSH keys) into the binary structure, which target services (PHP interpreters, cron daemons, SSH servers) will parse and execute while ignoring the SQLite header garbage. This bypasses many file-type validation controls.

Detection Guidance

Network/Protocol Indicators:

• Monitor for ATTACH DATABASE SQL commands on Anyquery server ports (typically 8070 or custom)
• Alert on any SQL commands containing path traversal sequences (../, ..\)
• Flag connections to Anyquery that issue SQL commands without prior authentication handshake
• Log all SQL statements executed, particularly those containing filesystem paths

Filesystem Indicators:

• Monitor creation of .db files in unexpected locations (web roots, /etc/cron.d, /root/.ssh)
• Alert on file modifications in sensitive directories (/var/www, /etc, /home/*/.ssh)
• Track new files written by the Anyquery process with embedded text payloads preceding binary data

Audit Logging:

• Enable SQLite query logging via PRAGMA query_only and statement logging
• Correlate unexpected .db file creation with inbound network connections

Mitigation Steps

Immediate Actions (Workarounds):

• Restrict network access to Anyquery server ports via firewall rules; only allow trusted internal IPs
• Run Anyquery with minimal filesystem permissions (dedicated user account, chroot/container isolation)
• Disable server mode if not actively required; use client-only mode
• Implement TCP-level access controls or use a reverse proxy with authentication/authorization checks

Long-Term Fixes (Patching):

• Upgrade to a patched Anyquery version that implements command whitelisting or disables ATTACH DATABASE
• Apply SQLite security pragmas: PRAGMA query_only = ON to prevent writes, or use PRAGMA compile_options to verify SQLite was compiled without dynamic attachment support
• Implement a SQL command parser that rejects ATTACH DATABASE, PRAGMA, LOAD_EXTENSION, and other dangerous commands before forwarding to SQLite
• Add authentication/authorization to server mode with per-user command restrictions

Risk Assessment

Likelihood of Exploitation: High. The vulnerability requires only network access and unauthenticated connections; no credentials or complex attack chains are necessary. Organizations running Anyquery in server mode on accessible networks face immediate risk.

Threat Actor Interest: Critical. This is a direct pre-auth RCE path—highly attractive to opportunistic attackers, worms, and ransomware campaigns. Public disclosure and PoC availability will accelerate exploitation.

Environmental Factors: Risk is amplified if Anyquery runs as root or with elevated privileges, or if internet-facing. Deployments behind firewalls or in air-gapped environments face lower risk, but internal threat actors and compromised development machines can still exploit it.

Recommended Response Priority: Deploy mitigation immediately; patching should be treated as emergency-priority.