Secure App Deployment
I posted this in another topic but I want to repost it here for a reason.
Most vendor apps are designed to install for the "common" user. This is the user who is a local admin, who will run the Setup.exe from a local drive or the internet and install the app, and if the "Finish" button comes up will think nothing more about the app unless the shortcut isn't there to click on.
In the corpporate world we deal with users who have NO rights. Can't install the app because we deploy it to them. Can't write to the hard disk/registry with any certainty etc. This is why we "repackage" vendor apps.
Vendor apps can be as slipshod and as nasty and reckless as they want to be because they only aim to hit the "Home User" type of people. Local admins.....omg!! lets all be local admins then you too can get hacked to the bejesus by any script kiddie with 2 spare weeks of school holidays up their sleeve.
Because of this the vendor is "allowed" to create dodgy custom actions and run scripts that don't work in the corporate world. ISS is one of these and is the main offender when it comes to creating "Unreal" apps. These are athe apps that WILL NOT install without local admin. This is just outrageous!
Adobe is a Prime offender......Not a local admin. Well forget it. You cant install Adobe Reader!!!!!
This is why we ALL repackage Adobe Reader!
We spend hours of our time to work out the registry keys to unblock or lock to stop users from doing harm to themselves or the business...this is the Corporate environment....but vendors don't get it.
I spend 80% of my time PROTECTING the platform within the bank I work in.....not from hackers but from vendor apps that will stick just any old dll in the System32 folder.
Why does a vendor dll "HAVE" to go into System32?
Why does a vendor HAVE to ship an Operating System DLL with their app?
This is the sort of thing that is OK for home users......but in the Corporate world when you have 30,000 users to protect.....the vendor app just doesn't cut it in most cases
I am interested to hear what other "repackagers" think of this concept and the growing threats we face daily.
Do you think of this at all?
Should you be thinking of this?
Your thoughts are always welcome.....lets hear them.
Most vendor apps are designed to install for the "common" user. This is the user who is a local admin, who will run the Setup.exe from a local drive or the internet and install the app, and if the "Finish" button comes up will think nothing more about the app unless the shortcut isn't there to click on.
In the corpporate world we deal with users who have NO rights. Can't install the app because we deploy it to them. Can't write to the hard disk/registry with any certainty etc. This is why we "repackage" vendor apps.
Vendor apps can be as slipshod and as nasty and reckless as they want to be because they only aim to hit the "Home User" type of people. Local admins.....omg!! lets all be local admins then you too can get hacked to the bejesus by any script kiddie with 2 spare weeks of school holidays up their sleeve.
Because of this the vendor is "allowed" to create dodgy custom actions and run scripts that don't work in the corporate world. ISS is one of these and is the main offender when it comes to creating "Unreal" apps. These are athe apps that WILL NOT install without local admin. This is just outrageous!
Adobe is a Prime offender......Not a local admin. Well forget it. You cant install Adobe Reader!!!!!
This is why we ALL repackage Adobe Reader!
We spend hours of our time to work out the registry keys to unblock or lock to stop users from doing harm to themselves or the business...this is the Corporate environment....but vendors don't get it.
I spend 80% of my time PROTECTING the platform within the bank I work in.....not from hackers but from vendor apps that will stick just any old dll in the System32 folder.
Why does a vendor dll "HAVE" to go into System32?
Why does a vendor HAVE to ship an Operating System DLL with their app?
This is the sort of thing that is OK for home users......but in the Corporate world when you have 30,000 users to protect.....the vendor app just doesn't cut it in most cases
I am interested to hear what other "repackagers" think of this concept and the growing threats we face daily.
Do you think of this at all?
Should you be thinking of this?
Your thoughts are always welcome.....lets hear them.
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
MSIMaker
18 years ago
Just in case your wondering where this thread is coming from I want to recommend this book to you
Protect Your Windows Network: From Perimeter to Data
I had the great fortune to meet the authors at Microsoft Tech-Ed here in Australia last week and they really got me thinking about the direction that security is heading with Longhorn and Vista coming soon.
I have read this book and it is a mind blower for anyone with any sort of lateral thought about the direction that Corporate/Enterprise security should be heading for the future. This security starts at the most basic level.....OS and apps.
What do we deploy....OS and apps?
I highly recommend this book and to quote the authors....."a little paranoia is a good thing and the person who got fired for Sasser smashing us wasn't paranoid enough."
Protect Your Windows Network: From Perimeter to Data
I had the great fortune to meet the authors at Microsoft Tech-Ed here in Australia last week and they really got me thinking about the direction that security is heading with Longhorn and Vista coming soon.
I have read this book and it is a mind blower for anyone with any sort of lateral thought about the direction that Corporate/Enterprise security should be heading for the future. This security starts at the most basic level.....OS and apps.
What do we deploy....OS and apps?
I highly recommend this book and to quote the authors....."a little paranoia is a good thing and the person who got fired for Sasser smashing us wasn't paranoid enough."
Posted by:
turbokitty
18 years ago
I find the biggest problem isn't getting them installed... most distribution apps have elevated rights to the machines. It's an issue with some apps when the distribution app needs to write to a current user hive (a non-ALLUSER install), but that's rare for me.
The biggest issue for me is that a lot of apps simply don't run after they're installed when the suer isn't an admin. I spend a lot of time using RegMon and FileMon to determine what keys and files I need to give the user admin rights to when installing the app.
Does anyone use a tool that's better than RegMon or FileMon? I personally think they're crap, but I can't find anything better... why can't a company come out with a tool that anaylzes an app in realtime and spits out a report with the keys/files I will need to assign "modify" access to???
The biggest issue for me is that a lot of apps simply don't run after they're installed when the suer isn't an admin. I spend a lot of time using RegMon and FileMon to determine what keys and files I need to give the user admin rights to when installing the app.
Does anyone use a tool that's better than RegMon or FileMon? I personally think they're crap, but I can't find anything better... why can't a company come out with a tool that anaylzes an app in realtime and spits out a report with the keys/files I will need to assign "modify" access to???
Posted by:
MSIMaker
18 years ago
Well personally I can't live without Regmon and Filemon. These are the BEST at what they do.
The reason apps don't run for users after they are installed is because most developers write programs with local admin rights and don't see the sort of mayhem they are going to cause once it hits userland.
This sort of development mentality is the thing that we need to make them aware of, so that apps run in the user context without opening dangerous registry keys and local file and folder permissions.
The reason apps don't run for users after they are installed is because most developers write programs with local admin rights and don't see the sort of mayhem they are going to cause once it hits userland.
This sort of development mentality is the thing that we need to make them aware of, so that apps run in the user context without opening dangerous registry keys and local file and folder permissions.
Posted by:
wiseapp
18 years ago
I agree with you Jim, these vendor provided MSI's that too on ISS are big nightmare for corporate packagers/application packagers working in corporate world. Sometime you do come out of these sick MSI's but most of the times I have seen you might end up creating a VB app/Script that should modify the system as per the client/corporate requirement and that's where the problem comes and meets with "Worst". I think most of the packagers who are working in corporate world try to create an MSI that is flexible enough to fit in any system be it corporate systems with GPO's or end-user desktops. In any case if any of these vendors are looking at this post, they should better try creating packages that are flexible enough to fit into corporate requirements. I think this would bring more confidence to the newbies of packaging.
What do you think Jim?
God Bless!
What do you think Jim?
God Bless!
Posted by:
MSIMaker
18 years ago
I think its time to illustrate a more defined way of giving "least privilege" users access to their applications instead of opening up the Windows registry like a can of sardines.
We need to start using smarter tools and processes to reduce the amount of possible damage that the "denial of service" and "worm" attacks of the past have inflicted.
This can be done...its a matter of developing a process and utilitising it.
We need to start using smarter tools and processes to reduce the amount of possible damage that the "denial of service" and "worm" attacks of the past have inflicted.
This can be done...its a matter of developing a process and utilitising it.
Posted by:
pauld
18 years ago
Threat Code
ThreatCode.com is a Hall of Shame for software that require Admin rights to run/don't support service packs/written in 16-bit code.
I'm looking at you, MYOB.
ThreatCode.com is a Hall of Shame for software that require Admin rights to run/don't support service packs/written in 16-bit code.
I'm looking at you, MYOB.
Posted by:
plangton
18 years ago
Hi Jim,
There’s an excellent MSDN blog (http://blogs.msdn.com/aaron_margosis/default.aspx) which is part evangelisation about running with least privilege and part technical information about how to make it happen.
In my (limited) experience, I don't tend to worry too much about application isolation until I experience problems, if a vendor MSI goes into the System32 directory, what’s the harm really? I know its bad design from the vendors, and it makes it ahrder to keep track of whats giong into the System32 directory, as long as it works and doesn't interfere with anything else then ... well I know it sounds lax but whats the problem? I worry more about applications that decide to use System32 as a repository for temporary files, so you have to gives users rights to the directory.
As detailed in this forum before, application isolation adds new security risks, in that patching your machine isn't enough, you need to go through your old packages and make sure versions of the DLL's that are isolated are also patched.
But basically, when packaging for non-admins, I run regmon/filemon, and add rights to individual files/registry settings where trying to redirect the application to more "least privilege" friendly locations doesn't work.
What I've been thinking of recently is a way of totally isolating applications, creating a virtual environment for it to operate in (so each application has a copy of the registry keys it requires in its local directory that it manipulates) - this has a few advantages and disadvantages of course, but its an interesting idea...
There’s an excellent MSDN blog (http://blogs.msdn.com/aaron_margosis/default.aspx) which is part evangelisation about running with least privilege and part technical information about how to make it happen.
In my (limited) experience, I don't tend to worry too much about application isolation until I experience problems, if a vendor MSI goes into the System32 directory, what’s the harm really? I know its bad design from the vendors, and it makes it ahrder to keep track of whats giong into the System32 directory, as long as it works and doesn't interfere with anything else then ... well I know it sounds lax but whats the problem? I worry more about applications that decide to use System32 as a repository for temporary files, so you have to gives users rights to the directory.
As detailed in this forum before, application isolation adds new security risks, in that patching your machine isn't enough, you need to go through your old packages and make sure versions of the DLL's that are isolated are also patched.
But basically, when packaging for non-admins, I run regmon/filemon, and add rights to individual files/registry settings where trying to redirect the application to more "least privilege" friendly locations doesn't work.
What I've been thinking of recently is a way of totally isolating applications, creating a virtual environment for it to operate in (so each application has a copy of the registry keys it requires in its local directory that it manipulates) - this has a few advantages and disadvantages of course, but its an interesting idea...
Posted by:
VikingLoki
18 years ago
All this is exactly why I incessantly complain to developers. Sometimes it produces better apps, usually it produces a "deer in the headlights" response.
What I'd REALLY like to see is an official MS document with a title akin to "Windows File System & Registry - What stuff belongs where". Not for myself, but to throw at developers after saying "USER DATA DOES NOT BELONG IN SYSTEM32, YOU #$%*^!!!!! RTFM!!!!" [:@]
Does anyone know if this document exists?
What I'd REALLY like to see is an official MS document with a title akin to "Windows File System & Registry - What stuff belongs where". Not for myself, but to throw at developers after saying "USER DATA DOES NOT BELONG IN SYSTEM32, YOU #$%*^!!!!! RTFM!!!!" [:@]
Does anyone know if this document exists?
Posted by:
plangton
18 years ago
Hi Turbokitty,
What exactly do you think is wrong with Filemon and regmon? As far as I am concerned they are perfect tools for what they do. I can't think of any others that even attempt to do what they do.
What exactly do you think is wrong with Filemon and regmon? As far as I am concerned they are perfect tools for what they do. I can't think of any others that even attempt to do what they do.
Posted by:
VikingLoki
18 years ago
Filemon & regmon can be a bit daunting before you get the hang of filtering. Every person I've trained in its use gets a deer in the headlights look the first time they monitor what they thought would be a simple thing. Nobody really expects that much data to be produced from a single mouse click. Add that to the fact that some ACCESS DENIEDs and FILE NOT FOUNDs are normal and expected, it can be overwhelming at first.
Once you get over the size of the data, know how to reduce it to what you're interested in and know how to spot "recovered" access failures they're indispensable tools!
Once you get over the size of the data, know how to reduce it to what you're interested in and know how to spot "recovered" access failures they're indispensable tools!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.