What's the easiest way to manage/maintain a whitelist?

What's the best way to go about it?

If you have something on a rapid release schedule you can whitelist certs, and that'll make things easier, but what about programs without certs? Path name would work but it's not secure. Hash would work but it would need constant updates for something on a rapid release schedule.

 

Hash rules will be a PITA for sure, unless you keep a mostly static setup.

As for Path rules, they are perfectly fine as long as you follow similar to what MrBrian did here Notice the directories he exempts from the whitelist that are user-writable. He's applying it to AppLocker of course, but the same approach will work in other Path-enforcement anti-executable setups.

 

In this case it would not be static and would be essentially system wide.

Hash is the most secure. I don't think path would really work for the situation. Certificates work where available...

I don't know any other way to validate lol

 

If you use AppLocker, Publisher rules are great, at least on programs they will apply to, otherwise you're looking most certainly at a mixture of primarily Publisher rules, with some Hash and possibly some path rules as well.

 

This wouldn't be through applocker, it would be a module to another program that I plan on writing.

Publisher rules are basically certs, right?

I have a question about that... let's say you have a Verisign cert for a program and a Verisign cert for another program - is there a way to differentiate between them? I think there is...

Like if both Chrome and Firefox were signed by Verisign but I only wanted one of them to be able to run... could I whitelist the very specific cert or would whitelisting Verisign allow them both to run/ not be able to differentiate?

 

Hopefully you find something that works for you.

Basically, the files have to either digitally signed or applied through different values within an internal certificate is the way I understand it. You can use one or a combination of Publisher name, file name or version number with a publisher rule.

Yes, the program name and/or version number.

 

Already got a large part of the overall planning done/ the ideas behind it are mostly there. Hopefully it works for more than just me =p

Awesome. That'll work really well for the ones that actually have a cert. I guess for ones that don't I'll need to whitelist the hashes.

 

Excellent, good luck with it

 

Tested it out. This will work well. Thank you.

 

If I really wanted to get that razoo with it, I would script it. The script would check the hash of current, get the hash of new, modify current hash to new, reload registry. I would make the interface bring up all hash entries, and then manually let the user decide "yes, I did update that program, so I want to update the hash".

Further could be done by creating a script that manually initiates the update, then computes the hash and compares if needed, and then modifies the hash entry.

Other ways come to mind as well. It would be a good learning project for sure, especially if you have never worked with hashes before. There are many great prebuilt options to use and also some good write-ups on coding the functions yourself. A little on the meaty side of things, but does teach a lot.

Sul.

 

Maybe I'll add an option but I don't want user-interaction to ever be necessary with the program.

 

*sniffs the air* Is that a future "hey guys, test this out" post I smell?

 

Probably lol but don't hold your breath =p I'm not planning to start any coding for months.

 

*Lets air out* Whew! Okay, I was starting to look like a Smurf Lol, anyway, I look forward to seeing what's cooking in the kitchen. Good luck!

 

Thanks. It'll definitely be the largest project I've worked on haha

 

I don't see any security problems with the path-based approach that wat0114 mentioned in post #2, except that manual auditing with AccessChk or similar should be done periodically to ensure that the permissions on files and folders where execution is allowed remain tight.

 

Path would not be what I want. If I'm trying to, for example, only allow Firefox.exe to run and the rule is "Only allow Firefox.exe to run for */downloads/" I have two issues.

1) If the user tries to run from elsewhere it's blocked
2) Any malware can name itself Firefox.exe

I plan on relying on hashes and certs.

 

Maybe check out PowerBroker Desktops or Privilege Authority (free versions available) for management of admin rights.

Regarding your second concern, if the malware didn't get admin rights, in my setup it wouldn't be in a location where AppLocker would allow its execution.

 

I'm not looking to find an application to do this, I'm looking to make one.

Also, the idea isn't to block/allow. That was only an example of where verification by path is weak and why I want to avoid it.

I don't see why it matters.

So you move it to a path that allows execution, believing it to be Firefox.exe, and it runs just fine because they share the name/path and that's all that's being validated.

 

Maybe this post would interest you: Using DLLCHARACTERISTICS’ FORCE_INTEGRITY Flag.

 

Yeah, he seems to be talking about certs there, which is what I'm going to rely on.

 

Who can we trust?

Is it possible to have whitelisted applications?

Certificates are supposed to provide this service... but who checks that the CA's
are really doing what they're supposed to be doing? At this point there's no real vetting on their part, they (some) just hand you the cert if you can pay for it.

So, really, is it possible to have a trusted CA?

 

Re: Who can we trust?

To answer your question, Yes.
Here’s the approach I use with AppLocker, and the same would apply with any other anti-executable program I’d use:

• My example application will be VMWare Workstation 8.
• Let’s say I’m interested in this application but I haven’t downloaded it yet, so I need to find a site that I think I can trust, so I choose the vendor’s site: -http://www.vmware.com/ca/en/support.html- An obvious choice, really.
• So far so good. I download VMWare Workstation 8
• Now here’s the important part. We have ourselves an installer from a well known site and vendor, it’s signed, but do you trust it 100%? If you are really prudent with security, you might not, so you should scan it first with updated av, maybe two av products.
• Assuming it comes up clean, you will probably go ahead and install it.
• You complete the installation, then test it to make sure it works as you more or less expect.
• Perfect, you are completely satisfied it really is VMWare Workstation and it works and behaves as the trusted application you sought in the first place.
• What has just been illustrated above is that it does not really matter if the installer was digitally signed or not; it still can’t necessarily be trusted implicitly either way, so it needs to be checked and verified first
• Now, you need to create an AppLocker whitelist ruleset for all the files installed within: C:\Program Files (x86)\VMware\ with sub-directories \VMware Workstation and \VMware Vix.
• This is where you might be surprised to find that not all the installed files are digitally signed! Check the screen caps and you will see that using my AppLocker rule generation method of choice – AutoGenerate – will first scan all the files, then create as many Publisher rules as possible, and any files not signed will be assigned a Hash rule (I could choose Path as well but I don’t).
• What we see here is that even though the main installer is digitally signed, not all the files it creates in the installation directory are, as I alluded to above, digitally signed. This is what you can sometimes encounter when creating rules for an installed application where the installer is digitally signed; not all the installed files are necessarily going to be signed.
• You have no choice but to create either Hash rules or Path rules for the files that are not signed. If you don't create rules for these files, AppLocker will block them
• What you will find, depending on the applications you intend to install, is sometimes all the installed files of a program will be signed, sometimes there will be a mix (as in my example) and sometimes none are signed, so they will require either Hash or Path rules.
• The important thing here, however, and it is why I can answer “YES” to your question:
• We have a verified and trusted application installed in a secured directory, one that is not modifiable by Standard users (one reason it is so important to run in a SUA).
• All of its installed files have been whitelisted with either, depending on the file, Publisher or Hash rules.
• It is installed in a secure directory; nothing from a Standard user account can write to that directory.
• AppLocker blocks unauthorized files from executing, so the only way malware can execute is if someone with administative control executes a malicious file unitentionally
• Obviously someone with administrative control has to exercise the necessary caution and *common sense* before executing any application for the first time

Hopefully this helps. I just wanted to go step-by-step through a typical scenario, and the thought process involved, especially where not all whitelisted files can necessarily be digitally signed.

*EDIT*

note in the second screen cap the enabled checkbox: "Reduce the number of rules created by grouping similar files". This is why there are fewer rules ( 8 ) than actual number of files ( 38 ) scanned. This helps to maintain a more efficient and manageable ruleset.

 

Re: Who can we trust?

Sure, for VMWare it's one thing. But what about other lesser known applications? Or something installing really critical things like a driver?

In your example much of that trust comes purely from having defenses built in (scanning with AV) as well as trusting the manufacturers site.

Is it possible to have a whitelist cert system in which the certs are legitimately trustable without other methods of verification ie: av scanning, trusting manufacturer etc.

 

Re: Who can we trust?

The question you make is a good one actually, IMO.

When you're downloading a digitally signed application, it isn't really a matter of just trusting the application, if it comes from a trustworthy source. When you put your confidence in a digital certificate, you're trusting the CA took all the precautions to be sure that the people requesting the certificate are the real deal.

So, my question is: Do we have reasons to give CAs all this trust? Or, in other words, are CAs doing everything they could do to help ensure the company is legitimate?



-edit-

This reminds me of a CA that gives/used to give certificates like crazy, but they weren't certifying the service (website) as safe; simply that the malicious website was the real deal, and not a bogus malicious website.