Blog | G5 Cyber Security

SQL Server to Web Server Attacks

G5 Cyber Security

TL;DR

Attackers can move from a compromised SQL server to your web server even without direct network access between them by exploiting features like Extended Stored Procedures, CLR integration, or using the SQL server as a proxy. This guide explains how these attacks work and what you can do to prevent them.

Understanding the Problem

Normally, firewalls block direct connections from your database server to your web server for security reasons. However, attackers are clever! They find ways around this by using the SQL Server itself as a stepping stone. They exploit features that allow SQL Server to execute code or make outbound requests.

How Attacks Happen

  1. Extended Stored Procedures (XPs): These let you run operating system commands from within SQL Server. An attacker gaining control of a SQL server can use XPs to create files, modify the webserver configuration or even execute code on the web server.
    • Example: Using xp_cmdshell to write a malicious script to your web directory.
    EXEC xp_cmdshell 'echo <malicious_script> > C:inetpubwwwrootevil.asp'
  2. Common Language Runtime (CLR) Integration: CLR allows you to write .NET code that runs inside SQL Server. Attackers can upload malicious assemblies and execute them, potentially making network connections.
    • Example: Creating a CLR assembly that connects to the web server on port 80 or 443.
    CREATE ASSEMBLY WebAttack FROM 'C:malicious.dll' WITH PERMISSION_SET = SAFE;
  3. SQL Server as a Proxy: The SQL Server can be configured to act as an HTTP proxy, allowing outbound connections that appear legitimate.
    • Example: Using sp_invoke_external_proxy (if enabled) to make requests to the web server.
    EXEC sp_invoke_external_proxy 'http://yourwebserver/evil.asp'
  4. Linked Servers: If a linked server is configured to connect to another instance that *can* reach the web server, an attacker can use the compromised SQL Server as a pivot.
    • Example: An attacker compromises SQLServerA which has a linked server connection to SQLServerB. SQLServerB can access the webserver.
    EXECUTE ('SELECT * FROM [SQLServerB].[DatabaseName].[SchemaName].[TableName]')
  5. Service Broker: This is a messaging framework within SQL Server. Attackers could potentially use it to send malicious payloads to the web server.

How to Protect Yourself

  1. Disable Extended Stored Procedures: This is one of the most important steps. Unless you absolutely need them, turn them off.
    • Command: EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE;
  2. Restrict CLR Integration: If you need CLR, carefully control what assemblies are loaded and grant only the necessary permissions. Avoid using PERMISSION_SET = UNSAFE.
    • Command: Review existing assemblies with SELECT name, assembly_file_path FROM sys.assemblies;
  3. Remove or Secure Service Broker: If you don’t use it, disable it. If you do, carefully configure security and access controls.
  4. Monitor Outbound Connections: Use network monitoring tools to detect unusual connections originating from your SQL Server.
  5. Principle of Least Privilege: Ensure the SQL Server service account has only the minimum necessary permissions.
  6. Regular Security Audits: Regularly review SQL Server configurations and logs for suspicious activity.
  7. Firewall Rules: While you likely block direct access, double-check that no unexpected outbound rules allow connections from your SQL server to your web server.
  8. Linked Server Review: Audit linked servers and ensure they are only connecting to trusted instances with appropriate security measures in place.

Further Resources

Consider researching the following for more detailed information:

Exit mobile version