Skip to content

Latest commit

 

History

History
80 lines (67 loc) · 13.5 KB

attack-surface.md

File metadata and controls

80 lines (67 loc) · 13.5 KB

Attack Surface Analysis for mariadb/server

Attack Surface: Unauthenticated Access via MySQL Protocol

  • Description: Exposure of the MySQL protocol port (default 3306) to untrusted networks allows attackers to attempt connections and potentially exploit vulnerabilities in the server's connection handling process or protocol itself, leading to unauthorized access without valid credentials.
    • Server Contribution: MariaDB server inherently listens on this port to accept client connections. The server's protocol implementation and connection handling logic are the core of this attack surface.
    • Example: An attacker from the internet scans for open port 3306, connects to the MariaDB server, and exploits a buffer overflow vulnerability in the server's handshake process to gain unauthorized access to the database or cause a server crash.
    • Impact: Unauthorized access to the database, data breaches, denial of service, full server compromise.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Network Segmentation: Restrict access to port 3306 using firewalls to only allow connections from trusted networks or specific IP addresses.
      • Disable Remote Access (if not needed): Configure MariaDB to listen only on localhost (127.0.0.1) if remote access is not required, preventing external connections.
      • Use Strong Authentication: Enforce strong passwords and consider using authentication plugins that offer enhanced security mechanisms beyond basic password authentication.
      • Keep Server Patched: Regularly update MariaDB server to the latest version to patch known vulnerabilities in the protocol and connection handling.
      • Implement Connection Limits: Configure connection limits to mitigate connection flooding Denial of Service (DoS) attacks.

Attack Surface: Weak or Default Credentials

  • Description: Using easily guessable passwords or retaining default credentials for administrative accounts (like 'root') provides attackers with immediate privileged access to the MariaDB server.
    • Server Contribution: MariaDB server relies on username/password authentication. Default accounts and the potential for weak password policies are inherent server configuration aspects that contribute to this risk.
    • Example: An administrator sets a weak password for the 'root' user or fails to change the default 'root' password after installation. An attacker brute-forces or guesses the password and gains full administrative control over the MariaDB server and all databases.
    • Impact: Full server compromise, complete data breaches, data manipulation and deletion, denial of service, and potential for further lateral movement within the network.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strong Password Policy: Implement and enforce a strong password policy that mandates password complexity (length, character types, no dictionary words) for all user accounts.
      • Change Default Passwords Immediately: Force the immediate change of default passwords for all administrative accounts, especially 'root', during the initial server setup process.
      • Regular Password Audits: Periodically audit user passwords for strength and enforce password resets or strengthen weak passwords.
      • Principle of Least Privilege: Grant only the necessary privileges to users and avoid over-privileging accounts, limiting the impact of a compromised account.
      • Multi-Factor Authentication (MFA): Consider implementing MFA for administrative accounts to add an extra layer of security beyond passwords.

Attack Surface: User-Defined Functions (UDFs) - Malicious Code Execution

  • Description: User-Defined Functions (UDFs) allow extending MariaDB functionality with custom code. If attackers can create or load malicious UDFs, they can achieve arbitrary code execution within the MariaDB server process context.
    • Server Contribution: MariaDB's UDF feature, while providing extensibility, inherently allows loading and executing shared libraries within the server process, creating a direct pathway for code execution if exploited.
    • Example: An attacker gains CREATE FUNCTION and file system write access privileges (potentially through SQL injection or privilege escalation). They create a malicious UDF (e.g., a shared library) that executes system commands when called, allowing them to take complete control of the server operating system.
    • Impact: Full server compromise, arbitrary code execution with server process privileges, complete data breaches, denial of service, and potential for using the compromised server as a pivot point for further attacks.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Restrict UDF Creation Privilege: Revoke the CREATE FUNCTION privilege from all users except highly trusted and authorized database administrators.
      • Disable UDF Loading (if not needed): If UDFs are not a required feature, disable UDF loading entirely through server configuration to eliminate this attack vector.
      • secure_file_priv Configuration: Strictly configure secure_file_priv to limit the directories from which UDF shared libraries can be loaded, significantly restricting the attacker's ability to place and load malicious UDFs. Set it to a highly restricted directory or disable file operations if possible.
      • Code Review and Security Audits for UDFs: If custom UDFs are absolutely necessary, implement rigorous code review and security audits of all UDF code before deployment to identify and eliminate potential vulnerabilities.

Attack Surface: Server-Side SQL Injection Vulnerabilities

  • Description: Vulnerabilities within MariaDB's core SQL parsing or execution engine itself can allow attackers to inject malicious SQL code that is processed by the server, potentially leading to data breaches, privilege escalation, or even server-side command execution. This is distinct from application-level SQL injection.
    • Server Contribution: MariaDB's fundamental function is parsing and executing SQL queries. Bugs or weaknesses in this core functionality represent server-specific SQL injection vulnerabilities.
    • Example: A vulnerability exists in MariaDB's stored procedure execution engine. An attacker crafts a specific SQL query within a stored procedure that bypasses internal security checks and executes arbitrary SQL commands with elevated privileges, allowing them to modify data they should not have access to or gain administrative privileges.
    • Impact: Data breaches, unauthorized data modification, privilege escalation within the database, potentially leading to server compromise if combined with other vulnerabilities or features.
    • Risk Severity: High to Critical (depending on the specific vulnerability, its exploitability, and the potential impact).
    • Mitigation Strategies:
      • Keep Server Patched - Priority: Regularly and promptly update MariaDB server to the latest version to patch known server-side SQL injection vulnerabilities and other security flaws in the core engine. This is the most critical mitigation.
      • Security Audits and Penetration Testing (Server Focused): Conduct regular security audits and penetration testing specifically targeting the MariaDB server itself, focusing on identifying potential server-side SQL injection vulnerabilities and weaknesses in the SQL parsing and execution logic.
      • Principle of Least Privilege (within SQL): Even within stored procedures and server-side SQL code, strictly adhere to the principle of least privilege to minimize the potential impact of any exploited SQL injection flaws. Limit the privileges granted to stored procedures and functions to only what is absolutely necessary.

Attack Surface: Insecure Default Configuration - Open Listen Port & skip-grant-tables

  • Description: Insecure default configurations, such as MariaDB listening on all interfaces (0.0.0.0) by default or accidentally enabling the --skip-grant-tables option, drastically increase the attack surface and can lead to immediate, unauthenticated access.
    • Server Contribution: MariaDB's default configuration settings, if not actively reviewed and hardened during and after installation, can introduce significant and easily exploitable security vulnerabilities.
    • Example: A MariaDB server is installed with the default configuration, listening on 0.0.0.0, making it accessible from any network. Furthermore, the administrator mistakenly enables skip-grant-tables for troubleshooting and forgets to disable it. An attacker from the internet connects to the server and gains full, unrestricted access to all databases and server functionalities without any authentication whatsoever.
    • Impact: Full server compromise, complete data breaches, data manipulation and deletion, denial of service, and the server becoming an open door for further attacks within the network.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Harden Server Configuration Immediately: Thoroughly review and harden the default MariaDB configuration immediately after installation and before exposing the server to any network.
      • Bind to Specific IP Address: Configure MariaDB to listen only on specific, internal IP addresses or localhost (127.0.0.1) if remote access is not required, limiting network exposure.
      • Disable skip-grant-tables in Production: Ensure that the --skip-grant-tables option is absolutely disabled in all production environments. This option should only be used in very specific recovery scenarios and with extreme caution, and disabled immediately afterward.
      • Regular Configuration Review and Automation: Implement regular reviews of the MariaDB server configuration to ensure ongoing adherence to security best practices and organizational security policies. Consider using configuration management tools to automate secure configuration deployment and prevent configuration drift.

Attack Surface: Data Exfiltration via SQL Features - Unrestricted File Access (LOAD DATA INFILE, SELECT ... INTO OUTFILE)

  • Description: SQL features like LOAD DATA INFILE and SELECT ... INTO OUTFILE, if not properly restricted by privilege management and secure_file_priv, can be abused by attackers to read arbitrary files from or write arbitrary files to the server's file system, leading to data exfiltration, server compromise, or data manipulation.
    • Server Contribution: MariaDB provides these SQL features for legitimate data import and export operations. However, insufficient privilege control and inadequate configuration of secure_file_priv can transform these features into significant attack vectors.
    • Example: An attacker compromises a user account that has the FILE privilege (or exploits a vulnerability to gain this privilege). They then use SELECT ... INTO OUTFILE to read sensitive files from the server's file system, such as application configuration files containing database credentials, SSH private keys, or even application source code. Alternatively, they might use LOAD DATA INFILE to overwrite critical system files if write access is possible.
    • Impact: Data breaches through exfiltration of sensitive files, server compromise by overwriting system files, information disclosure, and potential for further exploitation based on the compromised information.
    • Risk Severity: High to Critical (depending on the sensitivity of the files accessible and the potential for server compromise).
    • Mitigation Strategies:
      • Restrict FILE Privilege - Severely: Revoke the FILE privilege from all users except for a very limited number of highly trusted and strictly controlled database administrators. This privilege should be granted only when absolutely necessary and for the shortest duration possible.
      • secure_file_priv Configuration - Mandatory: Properly and strictly configure secure_file_priv to severely restrict the directories from which files can be loaded or written using LOAD DATA INFILE and SELECT ... INTO OUTFILE. Set it to a specific, highly restricted directory that is only used for legitimate data import/export operations, or disable file operations entirely by setting it to an empty string if these features are not required.
      • Input Validation and Sanitization (File Paths - if absolutely needed): If these features are genuinely necessary for legitimate application functionality, implement extremely careful input validation and sanitization of any user-provided file paths to rigorously prevent path traversal attacks and ensure that only intended files within allowed directories are accessed. However, it is generally recommended to avoid user-provided file paths for these operations if possible.