Hopefully we don't have whitelists for real malware (e.g. from big brother )

another similar question... on several places we have the notice to automatically trust signed executables, but how are the certifications for the signing controlled? i don't think it would be impossible for an malware author/group to get an certificate to sign their files, will KIS/KAV automatically set it as trusted?!

I was thinking about this too..... Recently saw a blog post about malware posing as flash player signed as "Jeanette K Murphy"....the digital signature seemed to be valid so would this file be able to run without and hinderance whatsoever?

another similar question... on several places we have the notice to automatically trust signed executables, but how are the certifications for the signing controlled? i don't think it would be impossible for an malware author/group to get an certificate to sign their files, will KIS/KAV automatically set it as trusted?!

- of course all certificates can be revoked (black listed) or signatures can be added for the detection etc. but all this happens after the attack. use of the file signing checking however is here sort of used as an proactive defense (and when done correctly can also be a very good one).- fake/not valid signed files or certificates are not really the issue here, it is about valid certificates that would be used to sign malware.- standard av signature/heuristics detection yes... however HIPS application control is used as another level of protection above this two so again signature and heuristics are not really the issue here since "the test case" for the effectivnes of the system should be an malware sample that was modified to evade the basic signatures and heuristics. also to note here is that several of the trusted signed executables have a high danger index by the HIPS internal heuristics.

i don't know how the sign checking mechanism is working (it is why i am questioning it here ), but i am afraid that it is working wrong. IMO it should not trust all signed applications but only those signed by known trusted certificates (a white list of certificates from microsoft, kaspersky, adobe,... should be used for this).

Without committing to the "+1" we shoulding be blacklisting certs without at least allowing or having specific whitelisted ones. Then this is a question, as I don't fully understand how you have set this up but it has been a concern for most of my testing the implications of this.

Speculative thinking here, what is to say the program can make these decisions, I realise you are aiming at that and using a third party to help with that line of approach, but there are still many holes as it is still young that you have not filled, and malware writers will find them. Saso's comments only highlight this for one section.

This post has been edited by norwegian: 16.05.2008 14:47

--------------------

The only thing necessary for the triumph of evil is for good men to do nothing - Edmund Burke

- of course all certificates can be revoked (black listed) or signatures can be added for the detection etc. but all this happens after the attack. use of the file signing checking however is here sort of used as an proactive defense (and when done correctly can also be a very good one).- fake/not valid signed files or certificates are not really the issue here, it is about valid certificates that would be used to sign malware.- standard av signature/heuristics detection yes... however HIPS application control is used as another level of protection above this two so again signature and heuristics are not really the issue here since "the test case" for the effectivnes of the system should be an malware sample that was modified to evade the basic signatures and heuristics. also to note here is that several of the trusted signed executables have a high danger index by the HIPS internal heuristics.

i don't know how the sign checking mechanism is working (it is why i am questioning it here ), but i am afraid that it is working wrong. IMO it should not trust all signed applications but only those signed by known trusted certificates (a white list of certificates from microsoft, kaspersky, adobe,... should be used for this).

Hello sasso,

I agree with you to 100 %. I wanted also to show my point of view but you do it better than me. I am not a specialist. I am impatient to know the KLab's arguments.

i don't know how the sign checking mechanism is working (it is why i am questioning it here ), but i am afraid that it is working wrong. IMO it should not trust all signed applications but only those signed by known trusted certificates (a white list of certificates from microsoft, kaspersky, adobe,... should be used for this).

i agree with that and asked ... the answer was that most of the time the certificates will be good ones so blacklisting will require less effort (and less heaaches for users whose applications will be restricted..)

So how often does a certified program have an exploit, quite a few times. So my question also is once something is exploited that is been allowed, how will it then be noted that a change has happened that would cause compromise? Simply because malware follows trends? Which has been allowed for in heuristics/Hips etc? Just curious.

--------------------

The only thing necessary for the triumph of evil is for good men to do nothing - Edmund Burke

i agree with that and asked ... the answer was that most of the time the certificates will be good ones so blacklisting will require less effort (and less heaaches for users whose applications will be restricted..)

on one side, i fully understand the decision made by KL and could even sort of support it... however on the other side, i know that personally i would strongly prefer the white listening approach. here are few thought to think about:

- file signing is one of those system that theoretically allow for 100% system protection.- whitelisting is also one of those systems that theoretically allow for 100% system protection since it allows you to have full control over the situation (only known good friends are allowed to the party ). in fact file signing is one way of whitelisting.- blacklisting allows you to only block known unwanted items so there is always a large number of the "unknowen", similar to what we have with the standard signature detection.

this system could (should?!) be a step above standard signature detection, but with the blacklisting approach i see it no different and so i question if it is really needed. ok, when i rethink again i see that it is used, but only to help users more automatically add their application to the list. IMO, this system has allot more power and unfortunately it is not used here.

i agree with the whole whitelisting aproach, or at least a popup when a signed application not known to the online database has a high threat leavel (75% for eg): "application is digitally signed but smells fishy, do you want to continue execution....)

unfortunatly at this time good apps with digital signatures >> bad apps with digital signatures, specially when you think that they come in variants (you can have 1000 zlob installers with the same digital signature for example). who knows maybe in time.

unfortunatly at this time good apps with digital signatures >> bad apps with digital signatures, specially when you think that they come in variants (you can have 1000 zlob installers with the same digital signature for example). who knows maybe in time.

indeed the situation at the moment is not really hot about this, however what do you think is more simple, to have whitelisting and have a list of maybe just 100 known valid safe certificates (IMO as little as 100 known good certificates could cover allot/most of user applications), or blocking (adding to blacklist) potentially thousands of certificates used by something like zlob once they find out that it works and that they are able to somehow get them.

Like appears in the article:"The big problem with a digital signature is someone can steal a copy of your private key, and you would never know it". So someone can obtain the SC and put some malware in that file and signed it.

File signing actually works on the same basic asymmetric cryptography principles as PGP. The certificate is actually more or less the same as an private and public key that enables you to sign your files (with the private key) and enables others to verify the signature (with the public key). File signing certificates however are normally produced and so also signed by an authorized party (for example some like VeriSign).

I would wish that stiling certificates (private keys) would not be an issue, that companies, specially those big ones, would know how to protect them, but unfortunately it has happened before that bad applications ware signed with microsoft certificate

But yes, we have probably went a bit to far off topic here... However IMO several good and important points have been pointed out in this discussion that could be reevaluated by developers for the future...