The Danger of Disabled Logins

When disabling sysadmin logins just ain’t enough

words: 691

Reading Time: ~3 minutes

Intro:

I’m becoming more and more of a fan of Powershell the more that I interact with it. And I’m a big fan of the work that those over at dbatools are doing (seriously, check it out and also check out their Slack channel).

So when reading an article by Steve Jones (b|t) that mentions using Powershell, especially dbatools, I took immediate attention!

However, while reading the blog, what jumped out at me was the fact that dbatools copies the logins and the passwords. I think that’s epic and saves so much hassle, especially with migrations and environment creation.

But when you script out a login in SSMS, you get the following “warning comment” (and this comes straight from Microsoft) :

/* For security reasons the login is created disabled and with a random password. */

I understand why you don’t want to script out a login’s password for security reasons but disabling it…does that even do anything?

Something that I only recently learned is that, for logins with high privileges, disabling them is not enough; they must be removed.

Overkill, I hear you say?

Example, I retort!

Example:

I will admit that for my example to work, there needs to be help from a member of the securityadmin server role login. So for this example we’re going to have…

  1. A disabled sysadmin login,
  2. A “compromised” securityadmin login,
  3. An “attacking” low-privilege login.

Window 1 (High Permission Account):


-- Create a high privilege login (HPL)
CREATE LOGIN [AllThePower]
    WITH PASSWORD = '1m5trong15wear!';

ALTER SERVER ROLE sysadmin
    ADD MEMBER AllThePower;

-- Disable it.
ALTER LOGIN AllThePower DISABLE;

-- Create a "compromised" login
CREATE LOGIN Enabler
    WITH PASSWORD = 'AlreadyHereButCompromised';

-- Make them part of security so can grant permissions
ALTER SERVER ROLE securityadmin
    ADD MEMBER Enabler;

-- Create a low privilege login (LPL)
CREATE LOGIN Copycat
    WITH PASSWORD = 'NotAsStrongButDoesntMatter';

 

 

So now we have all our actors created, we need to connect to the database with all 3 accounts.

Simple as “Connect” -> “Database Engine” -> Change to SQL Auth. and put in the details above for who you want.

Window 2 (CopyCat):

First things first, check who we are and who can we see?


-- Who are we?
SELECT
    SUSER_NAME() AS LoginName,
    USER_NAME() AS UserName;

-- Who can we see?
SELECT
    *
FROM sys.server_principals;

 

copycatsee
We can’t see “Enabler” or “AllThePower”

Okay, so we can’t see it but we know that it’s there.

Let’s just cut to the chase and start “God-mode”


-- Can we get all the power
ALTER SERVER ROLE sysadmin
ADD MEMBER CopyCat;

copycatinitialsysadminfail
It was worth a shot…

Can we impersonate it?

-- Can we impersonate AllThePower
EXECUTE AS LOGIN = 'AllThePower'
SELECT
    SUSER_NAME() AS LoginName,
    USER_NAME() AS UserName;

 

copycatinitialattemptfail
I’ve put the different possibilities on individual lines…We “do not have permission” btw

Time to go to our compromised account:

Window 3 (Enabler):

Now, who are we and what can we see?

enablersee
Sauron: I SEE YOU!

Notice that “Enabler” as part of securityadmin can see the disabled “AllThePower” login?

Great, we can see it, so let’s promote our CopyCat login!

enablerinitialattemptfail
Look but don’t touch

So even though we’re now a member of the securityadmin role, we still can’t promote our login!

I think you’d be safe in thinking that people would give up here, but we know from server_principals that “AllThePower” is there, even though it’s disabled!

So even though we don’t have the ability to promote our login, we do have something that we can do in our power.

GRANT IMPERSONATE.


-- Give CopyCat Grant permission
GRANT IMPERSONATE ON LOGIN::AllThePower TO CopyCat;

enablerinitialattemptsucceed
Every little helps

Window 2 (CopyCat):

Now can we impersonate our Disabled login?

copycatinitialattemptsuccess
Whoooo are you? Who-oo? Who-oo?

And can we get all the power?

copycatsecondattemptsuccess
I know an uh-oh moment when I see it…

Finally, we’ll revert our impersonation and see if we actually are sysadmin?


-- Go back
REVERT;
SELECT
SUSER_NAME() AS LoginName,
USER_NAME() AS UserName;

-- Are we superuser?
SELECT IS_SRVROLEMEMBER('sysadmin') AS AreWeSysAdmin;

CopyCatGodMode.PNG
I..HAVE..THE POWER!!!

And now I can do whatever I feel like, anything at all!

Summary:

I’m a fan of removing high-permission accounts that are not needed but I’ve never put into words why. Now I know why disabling is just not enough and, for me, removing them is the option.

Author: Shane O'Neill

DBA, T-SQL and PowerShell admirer, Food, Coffee, Whiskey (not necessarily in that order)...

One thought on “The Danger of Disabled Logins”

Leave a Reply

%d