Reading Time: ~3 minutes
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!
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…
- A disabled sysadmin login,
- A “compromised” securityadmin login,
- 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;
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;
Can we impersonate it?
-- Can we impersonate AllThePower EXECUTE AS LOGIN = 'AllThePower' SELECT SUSER_NAME() AS LoginName, USER_NAME() AS UserName;
Time to go to our compromised account:
Window 3 (Enabler):
Now, who are we and what can we see?
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!
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.
-- Give CopyCat Grant permission GRANT IMPERSONATE ON LOGIN::AllThePower TO CopyCat;
Window 2 (CopyCat):
Now can we impersonate our Disabled login?
And can we get all the power?
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;
And now I can do whatever I feel like, anything at all!
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.
One thought on “The Danger of Disabled Logins”