May 14, 2017 at 2:57 pm
I was reading the following recent article...
http://www.sqlservercentral.com/articles/SSIS/155160/
and realized I knew very little of the security behind SSIS, especially at the Task level.
To summarize the article, it uses the following 4 methods to demonstrate performance differences of simply copying files from one directory to another.
Here are the questions that came to my mind.
1. Which login is used to execute the task?
2. Is there anything that traces what was done to the file system (using any of the methods) to the actual human that ran the SSIS package?
3. A bit on the far side, is there any way to prevent the Execute Process Task from anyone using it to get to the Cmd Line or Powershell? Is there any way to disable the Script Task?
4. And finally, how do you prevent an attacker that managed to get in as a "high prived user" from using any of these methods to further their attack? (Yes, it is a bit of a trick question... that's why I'm asking to be sure.).
If there's a good link on the subject, I'd be very interested in that, as well.
Thanks for the help folks.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2017 at 5:55 am
Jeff Moden - Sunday, May 14, 2017 2:57 PM1. Which login is used to execute the task?
Depends how it was executed. From SSMS then it will use the credentials of the user connected, if scheduled as a SQL Agent job it will use either the SQL Agent service account or a proxy depending on how the job is configured.
Assuming the package is deployed you can view the execution reports on the SSISDB database. These will tell you the caller and what the steps were performed.
4. And finally, how do you prevent an attacker that managed to get in as a "high prived user" from using any of these methods to further their attack? (Yes, it is a bit of a trick question... that's why I'm asking to be sure.).
It's all down to rights. SSIS isn't a way for a user to do things they don't have rights to do. Can the user launch a cmd window and execute a specific command outside of SSIS? Then they can do the same in SSIS.
This does assume that the SQL Agent Account has the least privileges and access to the proxy accounts is controlled. If the SQL agent account is running as local admin or even domain admin then it is possible for a user to use this to inflate their rights (assuming they have privileges to deploy the package and create a SQL agent job)
May 15, 2017 at 7:46 am
Awesome. Many thanks for the help.
Your answer on question 2 brings up one additional question...
2. Is there anything that traces what was done to the file system (using any of the methods) to the actual human that ran the SSIS package?Assuming the package is deployed you can view the execution reports on the SSISDB database. These will tell you the caller and what the steps were performed.
Does any such logging occur during development and testing prior to package deployment? In other words, if someone broke in as a high privs user or service login, could they execute Cmd Line or Powershell scripts using the Execute Process Task (or whatever) without it being logged?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2017 at 9:35 am
Jeff Moden - Monday, May 15, 2017 7:46 AM
Does any such logging occur during development and testing prior to package deployment? In other words, if someone broke in as a high privs user or service login, could they execute Cmd Line or Powershell scripts using the Execute Process Task (or whatever) without it being logged?
In answer to your question yes it would be possible to execute a SSIS package without the execution being logged. be it through Visual Studio or DTexec. In order to run cmd or powershell on that server they need to execute the package directly on that server, if they have direct access they could execute the same cmd or powershell without using an ssis package.
December 21, 2017 at 4:54 am
This was removed by the editor as SPAM
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply