db_owner security risks
A typical web-tier should only need DB_USER level access to a backend SQL Server database. The DB_USER contains DB_Writer, DB_Reader – and optionally, DB_EXECUTE privileges.
Sometimes, web tiers will be designed to do more than just CRUD operations. For e.g. – a web app that creates database tables on the fly – would need a DDLAdmin level privilege.
Web Tiers of such applications need an almost full-blown db_owner privilege on their own database. The common response is – okay – since all you can do is damage to just your own database – not other databases on the instance. Turns out, that is far from true. A db_owner on any ONE database – can still bring down the entire server – and do other nefarious things.
What damage can a SQL Server db_owner do?
db_owner can write a trigger that can elevate her own priviliges to sysadmin
Db_Owner can alter the data file size – and fill up the entire diskspace.
–===============
–db_owner HACKER can CHANGE The data file sizes
–===============
ALTER DATABASE [mydatabase] MODIFY FILE
(
NAME = N’mydatabase’
, SIZE = 3000MB
, FILEGROWTH = 512MB
)
ALTER DATABASE [mydatabase] MODIFY FILE
(
NAME = N’mydatabase’_log’
, SIZE = 2000MB
, FILEGROWTH = 512MB
)
GO
Db_owner can keep creating new logins, ad infinitum – and fill up all available memory.
USE [master]
GO
CREATE LOGIN [foo] WITH PASSWORD=N’Some_really_difficult_pa$$word’
, DEFAULT_DATABASE=[iDBA]
, CHECK_EXPIRATION=OFF
, CHECK_POLICY=ON
GO
USE [iDBA]
GO
CREATE USER [foo] FOR LOGIN [foo]
ALTER ROLE [db_owner] ADD MEMBER [foo]
GO
Leave a Reply