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.

Answers

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."

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???

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.

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.

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...

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!!!!" [:@]

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!