Digitally signed executables and malware

[gottcha]

With malware being digitally signed becoming more popular I've been wondering how the current versions 7.x are dealing with them in general. Because I didn't have a chance to upgrade yet hopefully someone came across the answer.

Version 6.7 does prompt for unknown and/or changed executables when Component Control is configured accordingly. That is only true for digitally unsigned executables. For example I have never seen a prompt by Outpost for CCleaner or Recuva of which both are signed.

To see what Outpost does with an invalid signature I edited the CCleaner executable with an hex editor and changing one byte that wouldn't affect the ability to run the program. Windows will correctly state that the digital signature is invalid because of that modification yet Outpost does not prompt at all, neither because obviously the file hash has changed or the digital signature became invalid. Outpost does not even store the file hashes for signed modules.

Because of that behavior I contacted Agnitum Support asking for clarification and the only answer was if this was reproducible with 7.0. So I couldn't follow up on that matter yet.


What Outpost in my opinion should be able to do:

-Prompt for all modules regardless of them being digitally signed
-Check the validity for digitally signed modules if file hashes are not being tracked
-Track file hashes if validity of digital signatures cannot be guaranteed



Some reading material, pretty much on every single security orientated blog at the moment:
It's signed, therefore it's clean, right?
Signed Stuxnet Rootkit
Stuxnet and stolen certificates



P.S.: This is more of a general issue than something specific to Outpost Firewall but since that's the version I am using I posted in this forum. If however that's the wrong place I apologize.

[kronckew]

you might want to untick the box in the improvenet settings at the bottom regarding digitally signed apps....

i would hope agnitum are following this....

[burebista]

Things started to look ugly: Siemens: German customer hit by industrial worm.

[kronckew]

luckily so far the only one reported. the race is on for Microsoft &/or Siemens to come up with a patch before the malware baddies get their act together. i've disabled auto rule generation in general for the moment.

[burebista]

Originally Posted by kronckew

the race is on for Microsoft &/or Siemens to come up with a patch before the malware baddies get their act together.

Microsoft already have a "patch". Lame IMHO. No icons whatsoever after "patch".

[minoka]

Well, I followed the patch instructions a few days ago and looked again this am, but I see no difference in my icons appearance, i.e., they did not turn 'blank'. Yet the reg changes did stick... win xp sp3.
On win7 pro, only icons to websites, internet shortcut, became blank.

[kronckew]

i tried the 'patch' (microsloth list it as a 'work-around' rather than a fix), it turned all my start menu icons to the same blank page icon & it's very difficult to find things in the menu as they all look alike now with visual clues missing you have to read the whole list & ensure you actually select the right one, any menu 'folders' with sub items are also affected. i've unpatched & await the proper fix. i suspect that if you do not have one of the products affected (i do not), it is reasonably safe to stay unpatched, tho i have turned off auto-generating rules.

also found this on the virusbuster site:

Originally Posted by virusbuster

Windows Shell attacked
2010/07/20

Microsoft released a security advisory, which addresses a publicly reported vulnerability in Windows Shell. The company has seen limited, targeted attacks on this vulnerability.

The software giant is investigating reports of exploiting the hole. The vulnerability exists because Windows incorrectly parses shortcuts in such a way that malicious code may be executed when the user clicks the displayed icon of a specially crafted shortcut. This vulnerability is most likely to be exploited through removable drives. For systems that have AutoPlay disabled, customers would need to manually browse to the root folder of the removable disk in order for the vulnerability to be exploited. For Windows 7 systems, AutoPlay functionality for removable disks is automatically disabled.

In the wild, this vulnerability has been found operating in conjunction with the Stuxnet malware.

While Microsoft continues its investigation of the issue, it recommends that customers follow the guidance provided in Security Advisory 2286198.

Source: Microsoft.

the link is to the full MS article and has alternate work-arounds as well as linkink to burabista's 'patch' one. note that turning off autoplay on usb's is another mitigation.

[gottcha]

Originally Posted by kronckew

you might want to untick the box in the improvenet settings at the bottom regarding digitally signed apps....

i would hope agnitum are following this....

Those only apply to network and anti-leak rules if I'm not wrong. Anything automatic is disabled on my system (Auto-learn, ImproveNet, rule auto-creation) anyway without affecting my component control settings.

[kronckew]

agnitum have today released a new build 3377 to protect against the vulnerability stuxnet exploits in .lnk files. my icons are back