Our DBA has left some DTS Packages floating around with some connections using "sa" and the password is saved.



I'm trying to demonstrate to him the danger in allowing anybody to open this package as we can add/change/modify the package to do things, using SA credentials.



Any great examples I can present him to show him how dangerous it is? The one thing I can do is:

"SELECT * FROM master.dbo.sysxlogins"

Being able to do

SELECT * FROM master.dbo.sysxlogins

when logged in as the sa account is the least of you worries.

Remember sa is God and there is nothing they cannot do. He can drop all the
databases, remove others from the server etc.


--
--

Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.konesans.com - Consultancy from the people who know


"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Our DBA has left some DTS Packages floating around with some connections
using "sa" and the password is saved.



I'm trying to demonstrate to him the danger in allowing anybody to open this
package as we can add/change/modify the package to do things, using SA
credentials.



Any great examples I can present him to show him how dangerous it is? The
one thing I can do is:

"SELECT * FROM master.dbo.sysxlogins"

In message <uMCQ2mcbEHA.3864 (AT) TK2MSFTNGP10 (DOT) phx.gbl>, Joe Horton
<horj235 (AT) at (DOT) lni.invalid> writes

Open the package
Add an Execute SQL Task with DROP DATABASE MyImportantDB in it and run
it, well don't but you could!

By default an user can open a DTS package. They cannot extract the
password, but they can add code and change it, although they may not be
able to save, the damage can be done there and then since you have the
connection details ready to be used if not visible.

--
Darren Green (SQL Server MVP)
DTS - http://www.sqldts.com

PASS - the definitive, global community for SQL Server professionals
http://www.sqlpass.org

Assuming the service account would allow it and you have the d drive:

exec master..xp_cmdshell 'format d:'

Having sa-ed package and a 'good' service account you can ruin the server or do more elaborate schemes such as hi-jacking network or stealing confidential information, etc.
"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Our DBA has left some DTS Packages floating around with some connections using "sa" and the password is saved.



I'm trying to demonstrate to him the danger in allowing anybody to open this package as we can add/change/modify the package to do things, using SA credentials.



Any great examples I can present him to show him how dangerous it is? The one thing I can do is:

"SELECT * FROM master.dbo.sysxlogins"

Since it seems logical the DBA will have many such packages where he has 'sa-ed' the packages - is it just the norm to have passwords at the package level to preven users from using his connections?
"Ilya Margolin" <ilya (AT) unapen (DOT) com> wrote

Assuming the service account would allow it and you have the d drive:

exec master..xp_cmdshell 'format d:'

Having sa-ed package and a 'good' service account you can ruin the server or do more elaborate schemes such as hi-jacking network or stealing confidential information, etc.
"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Our DBA has left some DTS Packages floating around with some connections using "sa" and the password is saved.



I'm trying to demonstrate to him the danger in allowing anybody to open this package as we can add/change/modify the package to do things, using SA credentials.



Any great examples I can present him to show him how dangerous it is? The one thing I can do is:

"SELECT * FROM master.dbo.sysxlogins"

I do not think it normal that the DBA sa "sa-ed" anything. My opinion of
the sa account is you assign a strong password and put it in the fire safe.
You do not use it around the environment.

--
--

Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.konesans.com - Consultancy from the people who know


"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Since it seems logical the DBA will have many such packages where he has
'sa-ed' the packages - is it just the norm to have passwords at the package
level to preven users from using his connections?
"Ilya Margolin" <ilya (AT) unapen (DOT) com> wrote

Assuming the service account would allow it and you have the d drive:

exec master..xp_cmdshell 'format d:'

Having sa-ed package and a 'good' service account you can ruin the server
or do more elaborate schemes such as hi-jacking network or stealing
confidential information, etc.
"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Our DBA has left some DTS Packages floating around with some connections
using "sa" and the password is saved.



I'm trying to demonstrate to him the danger in allowing anybody to open
this package as we can add/change/modify the package to do things, using SA
credentials.



Any great examples I can present him to show him how dangerous it is?
The one thing I can do is:

"SELECT * FROM master.dbo.sysxlogins"

That is what passwords are for. I would say bigger the company more it should be a norm to password the packages. One should be watchful for other logins with sa rights as well. Especially with windows authentication. By default local admins and domain belong to BUILTIN\ADMINSTRATORS windows group and have sa rights on a server. So if the package is windows authenticated and the user if local admin...
"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Since it seems logical the DBA will have many such packages where he has 'sa-ed' the packages - is it just the norm to have passwords at the package level to preven users from using his connections?
"Ilya Margolin" <ilya (AT) unapen (DOT) com> wrote

Assuming the service account would allow it and you have the d drive:

exec master..xp_cmdshell 'format d:'

Having sa-ed package and a 'good' service account you can ruin the server or do more elaborate schemes such as hi-jacking network or stealing confidential information, etc.
"Joe Horton" <horj235 at lni dot wa dot gov> wrote

Our DBA has left some DTS Packages floating around with some connections using "sa" and the password is saved.



I'm trying to demonstrate to him the danger in allowing anybody to open this package as we can add/change/modify the package to do things, using SA credentials.



Any great examples I can present him to show him how dangerous it is? The one thing I can do is:

"SELECT * FROM master.dbo.sysxlogins"