pallino

file digitally signed

Recommended Posts

Hello Emsisoft Team,

How does Emsi handle a file digitally signed when this is executed?

Does Emsisoft immediately classify it as a "trusted program",  create ApplicationRules and allow it to run without any protection from the Behavior blocker or does BB still monitor it or only some behavior?

In other words, if a malicious file is digitally signed, when executed can it do whatever it wants or can Emsi still block malicious behavior?

Thank you

 

Share this post


Link to post
Share on other sites
On 7/24/2017 at 0:28 AM, pallino said:

Does Emsisoft immediately classify it as a "trusted program",  create ApplicationRules and allow it to run without any protection from the Behavior blocker or does BB still monitor it or only some behavior?

Rules are not automatically created for the Behavior Blocker when a program is digitally signed. The firewall is different, and thus in Emsisoft Internet Security you'll note rules being created for applications that are trusted based on digital signature.

 

On 7/24/2017 at 0:28 AM, pallino said:

In other words, if a malicious file is digitally signed, when executed can it do whatever it wants or can Emsi still block malicious behavior?

We blacklist digital signatures used by malicious software (as I understand it most other vendors do this as well). Malware doesn't generally get away with abusing digital signatures.

Share this post


Link to post
Share on other sites

GT500 thank you.

What happens when a file digitally signed is executed? What should  Emsi and Emsisoft's BB do?

Is the validity of the certificate checked, then If valid  a rule is added and all is allowed in BB & firewall?

Before the certificate is blacklisted the malware can do what it wants or some components of Emsi still check it?

Thank you

 

 

 

Share this post


Link to post
Share on other sites

Our server administrator tried to update our forums on Wednesday morning, and there were some problems that necessitated restoring from a backup, so the message I posted the other day is gone.

You should have received an e-mail with the contents of my reply from Wednesday morning. If you did not, then please let me know.

Share this post


Link to post
Share on other sites
On 7/25/2017 at 0:16 PM, GT500 said:

Rules are not automatically created for the Behavior Blocker when a program is digitally signed. The firewall is different, and thus in Emsisoft Internet Security you'll note rules being created for applications that are trusted based on digital signature

From what I get, an app carrying a digital signature 'trusted by Emsisoft' are fully trusted. What difference will Firewall (or EIS version) make in the crafting of rules?

On 7/25/2017 at 7:11 PM, pallino said:

What happens when a file digitally signed is executed? What should  Emsi and Emsisoft's BB do?

Is the validity of the certificate checked, then If valid  a rule is added and all is allowed in BB & firewall?

Before the certificate is blacklisted the malware can do what it wants or some components of Emsi still check it?

Thank you

 

 

 

@GT500 can you provide your answer over here? I would like to know about this scenario. 3 queries to breakdown:

  1. Does the Emsisoft client check if the certificate is valid+verified and then consider it 'trusted' (again, only in case the certificate is trusted by Emsisoft data) OR only the validity of the certificate trusted by Emsisoft is enough?
  2. If there is a malicious file sporting a certificate trusted according to Emsisoft (probably stolen), and the certificate is valid and verified, the malware will run without any monitoring unless the certificate gets blacklisted?
  3. Somewhat contrasting the 2nd point, I find that processes of quite some 'Trusted' programs are monitored, partially or fully. Can you explain on what basis is this determined (whether to monitor fully, partially, or not)?

Thank you!

Share this post


Link to post
Share on other sites
9 hours ago, Parsh said:

From what I get, an app carrying a digital signature 'trusted by Emsisoft' are fully trusted. What difference will Firewall (or EIS version) make in the crafting of rules?

The Behavior Blocker doesn't need rules to automatically allow applications that are trusted based on digital signatures, however the firewall actually needs rules to tell it what traffic to allow and what traffic to block. This is why more rules are created in EIS (which needs them for the firewall) than in EAM (which only needs them for unsigned files).

 

9 hours ago, Parsh said:

Does the Emsisoft client check if the certificate is valid+verified and then consider it 'trusted' (again, only in case the certificate is trusted by Emsisoft data) OR only the validity of the certificate trusted by Emsisoft is enough?

Windows validates certificates. EIS wouldn't be able to do anything more than Windows in regards to certificate validity.

 

9 hours ago, Parsh said:

If there is a malicious file sporting a certificate trusted according to Emsisoft (probably stolen), and the certificate is valid and verified, the malware will run without any monitoring unless the certificate gets blacklisted?

Such things have happened in the past, and as soon as a malicious file is seen using a legitimate certificate the certificate is blacklisted. Malware doesn't get away with abusing certificates for very long. Malware creators would have to frequently sign their binaries with new certificates in order to get away with abusing them for more than a few hours at the most.

 

9 hours ago, Parsh said:

Somewhat contrasting the 2nd point, I find that processes of quite some 'Trusted' programs are monitored, partially or fully. Can you explain on what basis is this determined (whether to monitor fully, partially, or not)?

When checking a program's reputation with the Anti-Malware Network, only those behaviors which the majority of users have allowed will be whitelisted, and this you may see that something is "partially" monitored due to those behaviors specified on the Anti-Malware Networking being considered safe.

Note that there are technical aspects of how the Behavior Blocker works that we are hesitant to discuss publicly due to the fact that malware creators read our forums. We don't want to reveal too much about how these validation mechanisms work, as that could make it easier to find ways around them.

Share this post


Link to post
Share on other sites

GT500,

The problem is that apparently Emsi completely trusts signed files and that a malware with a (still) valid certificate can infect/encrypt the device.

I just found another ransomware with valid certificate (a Globelimposter, I submitted yesterday, Sha b269b77b38e3fee6e445b04ef8ac9294a6062dc42dcbaf015d134abef308b5ef ).

I  saw that Emsi doesn't check it's AMN (where it is already detected as malware). The BB states the file is good and that it is being monitored (under BB protection tab after enabling to display trusted files).

If I check the rules, all is allowed (BB as firewall in/outbound).

If BB is monitoring it why were my files encrypted (all in desktop, documents, pictures) when normally Emsisoft blocks the ransomware immediately (when files are not signed)?

If memory serves some time ago you had an option to enable/disable "trust signed files"...can you add it again (at least in a "expert mode")?

 

Thank you!

 

 

Share this post


Link to post
Share on other sites

The file should be detected using the latest signatures. The digital signature has also been blacklisted.

Share this post


Link to post
Share on other sites

Why was the file detected as malware on the AMN (isthisfilesafe.com) but not by your fileguard/signatures?

Why didn't the BB detect the encryption of the documents, pictures etc or check AMN ?

Does BB still monitor something when a file has a valid certificate? 

I understand there are few cases of malware with valid certificate but I found 2 in the last days and read about more online (https://www.bleepingcomputer.com/news/security/crypt-globeimposter-ransomware-distributed-via-blank-slate-malspam/).

How can users get protection from cases like this until the certificate is blacklisted?

Before users could disable trusting signed files (if memory serves me), now it's not possible anymore.

 

Thank you

 

 

Share this post


Link to post
Share on other sites

Unfortunately I cannot give you any more details about the internal working of our protection components. You can however verify that both signature detection and behavioral detection work properly now for this and similar samples.

Share this post


Link to post
Share on other sites
On 8/1/2017 at 9:17 AM, GT500 said:

When checking a program's reputation with the Anti-Malware Network, only those behaviors which the majority of users have allowed will be whitelisted, and this you may see that something is "partially" monitored due to those behaviors specified on the Anti-Malware Networking being considered safe.

Thank you Arthur and Elise for your answers. The use of (kindof) collective intelligence is fascinating. 

 

On 8/1/2017 at 9:17 AM, GT500 said:

Such things have happened in the past, and as soon as a malicious file is seen using a legitimate certificate the certificate is blacklisted. Malware doesn't get away with abusing certificates for very long. Malware creators would have to frequently sign their binaries with new certificates in order to get away with abusing them for more than a few hours at the most.

Note that there are technical aspects of how the Behavior Blocker works that we are hesitant to discuss publicly due to the fact that malware creators read our forums. We don't want to reveal too much about how these validation mechanisms work, as that could make it easier to find ways around them.

 

On 8/1/2017 at 7:44 PM, Elise said:

The file should be detected using the latest signatures. The digital signature has also been blacklisted.

I ended up sensing the same concern. Sure the intricate details of BB etc. are better kept contained. 

However regarding the certificate issue, it boils down to this: 

Users are mostly not protected from malware carrying a valid/legitimate certificate unless the certificate is manually blacklisted (like the Philadelphia or the Global-Imposter seen recently), be it the same day or later (not all malware get reported). Until the manual blacklisting, any loss of system stability and data caused by such malware is indirectly allowed and the Behavior Blocker, that is integrated to be the strength of the product against unknown and zero-day threats, is rendered ineffective due to limited or no monitoring of such malware. 

Call it a tradeoff between protection and ensuring minimal FPs. All this when a simple option (you know) could possibly prevent havoc atleast for the users who're aware about how to use it. The default can be kept to "Trust valid signed files". I hate comparing, but there are a few vendors that provide this option. Since some options like - enabling or disabling "Automatically allow programs with good reputations" (disabling which can result in increased FPs/user decisions needed) are provided ... why cannot an option be included to enable/disable trusting such signed files? It's then up to the user like in case of some other already available options as discussed above. Thank you for reading through the suggestion.

Share this post


Link to post
Share on other sites
18 minutes ago, Parsh said:

Users are mostly not protected from malware carrying a valid/legitimate certificate unless the certificate is manually blacklisted (like the Philadelphia or the Global-Imposter seen recently), be it the same day or later (not all malware get reported).

The issue with this statement is that, once we blacklist the certificate that a malware developer is using to sign their malicious files with, all of the files signed with that certificate are suddenly blocked. That means that they need to sign new binaries and start distributing them. Unless the criminals are good at stealing certificates to sign binaries with, or don't mind blowing a ton of their ill-gotten cash on certificates, there's a limit to how much this can be done. I'm not saying that we'll block an entire family of malware by blacklisting one certificate, but I am saying that it isn't a viable way to bypass security software in the long term.

 

24 minutes ago, Parsh said:

Call it a tradeoff between protection and ensuring minimal FPs. All this when a simple option (you know) could possibly prevent havoc atleast for the users who're aware about how to use it. The default can be kept to "Trust valid signed files". I hate comparing, but there are a few vendors that provide this option. Since some options like - enabling or disabling "Automatically allow programs with good reputations" (disabling which can result in increased FPs/user decisions needed) are provided ... why cannot an option be included to enable/disable trusting such signed files? It's then up to the user like in case of some other already available options as discussed above. Thank you for reading through the suggestion.

We used to have an option called "Paranoid Mode" available that stopped the Behavior Blocker from automatically allowing executables based on digital signatures. When people would use it the feature would cause havoc on their computers, and they'd of course complain about the ridiculous number of alerts or the fact that their computers didn't work properly (or at all). We eventually were forced to remove the feature, as it did very little to improve security and was more likely to cause problems, frustration, and confusion.

Share this post


Link to post
Share on other sites
57 minutes ago, GT500 said:

The issue with this statement is that, once we blacklist the certificate that a malware developer is using to sign their malicious files with, all of the files signed with that certificate are suddenly blocked. That means that they need to sign new binaries and start distributing them. Unless the criminals are good at stealing certificates to sign binaries with, or don't mind blowing a ton of their ill-gotten cash on certificates, there's a limit to how much this can be done. I'm not saying that we'll block an entire family of malware by blacklisting one certificate, but I am saying that it isn't a viable way to bypass security software in the long term.

Maybe "until" is better suited in place of "unless" in the first line. Your point is totally valid and the set of malware using the same certificate will be blocked. Those cyber-criminals will have to lighten their pockets to continue ..

What I am focusing is about the window between 'some or many users falling pray to malware signed with legit certificates' and 'Emsisoft team blacklisting the certificate to prevent further infections'. 

 

57 minutes ago, GT500 said:

We used to have an option called "Paranoid Mode" available that stopped the Behavior Blocker from automatically allowing executables based on digital signatures. When people would use it the feature would cause havoc on their computers, and they'd of course complain about the ridiculous number of alerts or the fact that their computers didn't work properly (or at all). We eventually were forced to remove the feature, as it did very little to improve security and was more likely to cause problems, frustration, and confusion.

That sure sounds paranoid. I'm sure you all would have discussed about the pros and cons about it and eventually let an option down due to user confusion. But the alert thresholds need not be the same for the signed and the unsigned files, should they be?

There can be some threshold (or such standards can be developed and continuously evaluated), dissimilar to the threshold for unsigned/semi-trusted/untrusted files, for different types of actions taken by the signed files that most likely indicate a malicious nature and present an alert to those "paranoid mode" users. Kaspersky System Watcher evaluates any potentially malicious actions by adding a score for each such action and reduces score for any following safe action sequence..thus forming a threat score. The process is considered malicious when a certain threshold is reached. This one is known to produce quite less FPs even with the "trust digitally signed files" disabled - just an example (I'm aware that handling might differ from Emsisoft, but they can be a mid-way). 

Very famous and critical apps that are known to be trusted, that can result in instabilities if blocked while issuing an alert, can be whitelisted in BB, however the others can be partially monitored - all this to reduce possible instabilities and this will include research you know that, researching problems is the way for solving such known hindrances instead of dropping the good options. The devs ofcourse know things better, I'm a normal user recently switched to Emsisoft and am concerned about some points. So please do not take this in a wrong way. What's the point of a strong BB in the case some signed malware can trash my system/encrypt my valuables before you blacklist the certificate manually? Such occurrences cannot be said to be rare, can these be? The other users will sure be protected after the blacklisting. 

To continue, famous apps presented with an alert will most likely be an FP while an unknown/non-famous app (though trusted due to the signed nature) being alerted about raises suspicion for sure. Again, do realise that we're talking about the paranoid users only and with an added assumption that the alerts for such digitally signed files can be optimized from your side. The paranoid mode can have a warning for the better. In short, the paranoid mode could be improved. The rest and most of users should have no issues by being oblivious to/staying away from this mode.   

The above points can be pondered over or re-evaulated, or the concept can directly be trashed again without possible strategy-based improvements. 

 

Share this post


Link to post
Share on other sites

It seems to me that 'paranoid mode' is sensibly off for what you might call 'naive' users...  But I am much less convinced that expert users should be denied that level of protection if they are able and willing to negotiate their way through false positives.  Just as it's possible not to quarantine things, but produce an alert and let the user decide what to do - which is how I run EIS - I would prefer paranoid mode to be accessible.  

Suppose EAM/EIS ship with paranoid mode off.   If it were again possible to turn it on, but doing so produced a dialog pane that explained that this wasn't suitable for non-technical users as the alerts it will cause need technical knowledge to judge, wouldn't that be subject to much less misuse?  Also, if the system is capable of not alerting about something in non-paranoid mode, it should be possible for an alert that's only generated in paranoid mode to say so.  In other words a non-technical user who ignores the warning/confirmation and turns paranoid mode on would then every time that one of the 'ridiculous number of alerts' is produced, be reminded that this was a consequence of them turning that mode on.

(I'm also not a fan of 'always allow' except for mainstream applications eg Firefox.  For other much-less monitored (by millions of users, I mean, not BB) applications setting 'always allow' because a user thinks an application is safe (and it may be, now) is a mistake.  The programmer might subsequently add a feature that - to be safe - I'd want to see cause another alert in future.)

Share this post


Link to post
Share on other sites
22 hours ago, Parsh said:

What I am focusing is about the window between 'some or many users falling pray to malware signed with legit certificates' and 'Emsisoft team blacklisting the certificate to prevent further infections'.

Anything widespread enough to effect a significant portion of our users, and we would notice it rather quickly. Even if our malware analysts discover it themselves, they'll see it on a Twitter feed or something when another analyst finds it.

 

22 hours ago, Parsh said:

But the alert thresholds need not be the same for the signed and the unsigned files, should they be?

We would (and still do) show file information in alerts, so users could see the information about the digital signature in the alerts.

 

19 hours ago, JeremyNicoll said:

If it were again possible to turn it on, but doing so produced a dialog pane that explained that this wasn't suitable for non-technical users as the alerts it will cause need technical knowledge to judge, wouldn't that be subject to much less misuse?

Warnings, unfortunately, didn't do enough to dissuade people from turning the feature on and expecting that their computer would operate normally.

 

19 hours ago, JeremyNicoll said:

Also, if the system is capable of not alerting about something in non-paranoid mode, it should be possible for an alert that's only generated in paranoid mode to say so.

Altering the format of alerts on a per-mode basis (or especially to represent signed files differently) requires a lot of GUI programming work, and would more than likely also introduce a lot of bugs. Considering that EAM/EIS are primarily marketed to home users, that's a lot of time and effort to put it for a feature that is going to be used by a very tiny percentage of users.

Obviously I'm not saying that such changes won't happen. Plans can always change, and priorities can always shift. That being said, for now I don't think we have any plans for any such changes.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.