Full Report
I was playing with a few SQL server idiosyncrasies more than a year ago before becoming so completely distracted with the whole SAP protocol-decoding business. Having some time on my hands for once, I thought I would blog it. Early last year, I found it possible to create jobs owned by other users on MS SQL Server (2000, 2005 and 2008) by an unprivileged user – providing the user had the capability of creating or altering stored procedures in the [master].[dbo] schema. The reason for this, comes as a result of cross-database permissions being chained, by default, across the system databases [master], [msdb] and [tempdb]. According to Microsoft, this is by design.
Analysis Summary
# Vulnerability: Unprivileged User Creation of Higher-Privilege SQL Server Jobs
## CVE Details
- CVE ID: Not explicitly assigned in the provided context (This appears to be an unpatched or internally reported issue at the time of blogging, or perhaps only tracked via internal vendor advisories).
- CVSS Score: N/A (Score not provided)
- CWE: CWE-284 (Improper Access Control) or CWE-269 (Improper Privilege Management) likely apply.
## Affected Systems
- Products: Microsoft SQL Server
- Versions: SQL Server 2000, SQL Server 2005, SQL Server 2008
- Configurations: Requires an unprivileged user to have the capability to create or alter stored procedures in the `[master].[dbo]` schema. This is often possible due to default cross-database chaining permissions between `[master]`, `[msdb]`, and `[tempdb]`.
## Vulnerability Description
The vulnerability stems from default cross-database permissions chained across SQL Server's system databases (`master`, `msdb`, `tempdb`). If a low-privileged user possesses `CREATE` or `ALTER` permissions on stored procedures within the `[master].[dbo]` schema, they can leverage an existing stored procedure to insert arbitrary records directly into sensitive tables within the `msdb` database, specifically `[msdb].[dbo].[sysjobs]` and related job step tables.
By manually setting the `[owner_sid]` field in `[msdb].[dbo].[sysjobs]` (e.g., to `0x01` for the `sa` user) and configuring the job step user to `sa`, the attacker can create a scheduled SQL Server Agent job that executes with the high privileges of the `sa` account, bypassing checks built into native job creation procedures like `sp_addjob`.
## Exploitation
- Status: PoC available (A zip file containing procedures for SQL 2000 and SQL 2005/2008 was made available by the researcher).
- Complexity: Medium (Requires prerequisite permission on `master.dbo` stored procedures, but the job creation payload itself is direct insertion).
- Attack Vector: Local (Requires the attacker to already have database access with specific stored procedure creation rights).
## Impact
- Confidentiality: High (An `sa`-context job can access all data and perform system configuration changes).
- Integrity: High (An `sa`-context job can modify or delete any system object or user data).
- Availability: High (An `sa`-context job could be configured to halt SQL Server Agent or corrupt system tables).
## Remediation
### Patches
- No explicit patch identification was provided, as Microsoft reportedly stated the cross-database behavior was "by design." Specific vendor advisories for CVEs related to this flaw are not detailed in the text.
### Workarounds
1. **Restrict Permissions:** Ensure that unprivileged users *cannot* create or alter stored procedures in the `[master].[dbo]` schema.
2. **Follow Best Practices:** Adhere to Microsoft's recommendation and avoid creating any user objects within the system databases (`master`, `msdb`, `tempdb`).
3. **Limit Environment:** The newly created job will only execute *after* the SQL Server Agent service is restarted, which may limit immediate impact if the service is stable or restarted infrequently.
## Detection
- **Indicators of Compromise (IoCs):**
- New entries appearing in `[msdb].[dbo].[sysjobs]` or `[msdb].[dbo].[sysjobsteps]` owned by high-privilege accounts (like `sa`) that were not created by administrative means.
- SQL Audit logs showing stored procedure execution in `master.dbo` by low-privileged accounts that result in unauthorized writes to `msdb` tables.
- **Detection Methods and Tools:**
- Regular auditing of membership in roles that grant permission to modify objects in `master.dbo`.
- Monitoring direct programmatic inserts/updates into system tables like `msdb.dbo.sysjobs`.
## References
- Vendor Advisories: Not explicitly cited, but the reliance on default cross-database permissions is noted by Microsoft as intended behavior.
- Relevant Links:
- SensePost Article: `hXXps://sensepost.com/blog/2012/privilege-escalation-in-sql-server-depending-on-some-dodgy-requirements/`
- Download Link (PoC): `hXXps://introonet.sensepost.com/blog/wp-content/uploads/2012/08/sql.zip`