Sign up to our newsletter
Someone raised an interesting point in a comment to yesterday’s blog about Symantec’s own PIFTS.EXE being flagged by their own firewall as a possible problem. Let me quote the comment in full.
I by no means buy into the super root-kit routine, I do however think that there will be copy cats (if not already) that are passing themselves off as “OOPS, I’m just an unsigned update, sorry, just install me anyways and we’ll be gravy”.
Hoax, scam, conspiracy theory lore, ya, already. But something not to warn your users about? Definitely not.
I started to respond to this as a follow-up comment, but thought it probably deserved a fuller response.
Fake patches are already common, and not usually signed. I don’t think of a way in which malware could pass itself off as an unsigned update without inviting the question "so -why- isn’t this update signed when the sender acknowledges that it ought to be?" Certainly I wouldn’t expect security software to be fooled by social engineering. Hopefully. (Of course, I realize that security software can be compromised indirectly when a human falls for social engineering.)
However, I suppose it’s quite possible that someone will try the "we weren’t able to sign this because the digital pen ran out out virtual ink" approach, and there’s probably someone, somewhere who will fall for it. Certainly there are plenty of people who have no idea of how code signing and digital signatures in general work, and it’s perfectly true that the bad guys are very adept at misusing and misrepresenting a security concept so that they can use it as an attack. On the other hand, it’s not unknown for fake patches to be sent out with a fake digital signature.
However, what we’re discussing here is two different issues. Fake patches are sent out using common and easily misused transport mechanisms like email attachments or forged, malicious links. In such a case, a fake signature, where used, is usually just a dummy. It’s there to fool the human being who receives the lure (social engineering), not the software.
In fact, Symantec’s firewall was doing just what it was supposed to do: if the executable had been signed, as it was supposed to have been, the issue would not have arisen, because the firewall could have authenticated it. As the situation did arise, the firewall quite properly flagged it as a possible problem. It was a glitch in the process rather than a technological error.
But you’re quite right: the bad guys are always looking for new angles to exploit human psychology: it’s much easier to patch and hotfix software than it is naïve human behaviour.
David Harley BA CISSP FBCS CITP
Director of Malware Intelligence
Author David Harley, ESET