Jump to content
Sign in to follow this  
saso

digital signatures and certificates

Recommended Posts

saso   
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?! :huh:

Share this post


Link to post
Share on other sites
Baz^^   

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?

Share this post


Link to post
Share on other sites
saso   
-there's a blacklist of digital signatures;

-if the signature is not valid (fake) it's ignored

-if the analysis finds a malware inside (even heuristically) it's untrusted regardless of certificate

 

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

Edited by saso

Share this post


Link to post
Share on other sites

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.

Edited by norwegian

Share this post


Link to post
Share on other sites
- 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 %. :bravo:

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites
saso   
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.

Edited by saso

Share this post


Link to post
Share on other sites
saso   
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.

Edited by saso

Share this post


Link to post
Share on other sites
claudiu   

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.

Share this post


Link to post
Share on other sites
claudiu   

It's about java applet like appears in the article:"When an Applet is created, the vendor creates a secret key SV and a public key PV". What about it?

Share this post


Link to post
Share on other sites
saso   

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 :huh:

 

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

Edited by saso

Share this post


Link to post
Share on other sites
claudiu   
i know, but at this moment, that software is protected as saso said (the technology is also evolving, so problems ocured while it was young but it has reached a certain maturity)

why exactly do you have to repeat what saso said and copy chunks from the comodo website...which i don't think is allowed btw.

First of all I didn't repeat what saso said.

Second I copied from an authorized company that works with code signing because of what you said above: "a private key is something else, it reffers to the pgp key for example or the key in a java applet, not to the certificate of an application."

Share this post


Link to post
Share on other sites
saso   

based on some private discussion about this with francgaulois i would like to highlight one more issue about this. in the above posts we have mostly discussed this issue with signed application trust from the stand point of real malware using it. the conclusion i guess was that our points are generally valid but that the situation with malware using them is at the moment not critical and so for now we are sort of ok with what we have.

 

however an application firewall should IMHO be used not just for controlling real malware, but any sort of applications, even those from valid and generally trusted companies. one more reason IMO for the white listing of certificates (even user management of this certificates white list?). the new HIPS in KIS8 is powerful and at this power advance users should have the ability to manage it. the option of interactive or automatic application trust management comes in to my mind here... just thoughts for future development :)

PS i use and will continue to use KAV and i use no other firewall or HIPS because i don't like to spend time with them :)

Edited by saso

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×