Breaking into SQL Server

Breaking into SQL Server

I recently had a situation where I needed to access a SQL Server that I didn’t have permissions to. This was a bit inconvenient and always in such a situation, the SQL Server was experiencing difficulties that needed a quick resolution.

An Application had been installed by someone with Domain Administrator privileges. The Application Installed itself an instance of SQL Server Express Edition, created a ‘sa’ Account and kept the Account details to itself. This become a problem because no-one else had administrative access to the SQL Server.

In early versions of SQL Server, Domain Administrators automatically received “system administration” access to the SQL Server. This was not ideal since it meant that a wide group of users had full access to change the SQL Server settings, not to mention access potentially sensitive data held within. This loophole was fixed in SQL Server 2008 and all Accounts need to be explicitly granted access to SQL Server in order to log in.

Now, I needed to log into the SQL Server Instance and found that I had no access. I checked the Account that the Service was running under – it was NT AUTHORITY\LOCALSERVICE

First thoughts were to create a new Domain account and set SQL Server to run the Instance under this Account.

I then tried logging in using the newly created Domain account that was running the SQL Server Service, but this did not have access either.

The answer was to run SQL Server in Single-User mode. In this mode, members of the local Administrators group on that Server receive ‘sa’ permissions automatically. To do this properly, I added the following to the Startup Parameters “-m SQLCMD” to the SQL Server Instance.

After adding the Parameter, SQL Server needs to be re-started.
You will only be able to connect using SQLCMD – i.e. SSMS cannot be used until the parameter has been removed.

Next, open a CMD window and navigate to the appropriate BINN directory for the SQL Instance that you want to log into.
I used “SQLCMD -S. -E” to log onto the local SQL Instance with my Windows Account.
SQLCMD provides command line access to SQL Server. From here, I was able to create a Login for myself and grant myself the sysadmin permissions – i.e.

CREATE LOGIN [Domain\UserName] FROM WINDOWS;
ALTER SERVER ROLE sysadmin ADD MEMBER [Domain\UserName]
EXIT

After providing access to my regular Account, I went back removed the single-user Startup parameter and re-started SQL Server. It was possible to login once more.

My learnings from this experience were:

  1. Try to keep more of an active watch on new SQL Server installs that may have been made within Application installs. This can be performed using network scanning software that sniffs out SQL Server installations – Idera do a free tool here: https://www.idera.com/productssolutions/freetools/sql-instance-check
  2. SQL Instances using Express Edition need plenty of attention too

  3. It’s really not so hard for someone to access your SQL Server, alter something and then remove their access again afterwards. Consider using a Security Logging tool or keeping an eye out for strange Server Stop / Starts and to record accords that have experienced

Leave a Reply

Your email address will not be published.

Follow on Feedly

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close