Does the IMON HTTP scanner pre-filter encoded characters?

Hi Everybody,

IMON's HTTP scanner is a great new feature for NOD32, but can it pre-filter encoded characters that crackers use to conceal their code?

For example:
<& #115;cript type="java& #115;cript">"

or this:
document.write('<'+'j'+'a'+'v'+'a'+'s'+'c'+'r'+'i'+'p'+'t'+'>')

or URL encoding like this:
http ://www.goodwebsite.com/site/dir/he...%4E%23%76%31%7F [insert nasty javascript url encoded here]

The above are just a few examples. One could encode more characters and perhaps combine two methods like the encoding in the first example with concatenation (second example). Using these methods, IMON's scanner may possibly be bypassed to let malicious code through. Unless, IMON is able to pre-filter these encoded characters to convert them to regular characters for normal scanning.

 

I have a email with the following line: X-Message-Info: 6sSXyD95QpWgCBWUvHx8NNdDCbTE47+p added to the very beginning of the email which stops Nod32 detecting the email as infected with a right click scan.

To quote someone from Eset: “If this line of text is removed, NOD finds the virus instantly. Because IMON can't scan every single word in every single email.... think of resources required!..... it can only scan the attachments. This virus has arrived actually in an email, so the viral code is written into the email message body itself. Now normally, IMON or NOD's on-demand scanner would still pick this up, but because that line of text has been added at the beginning, it thinks this is some kind of file that it doesn't recognise.

Eset will add this line to their detection database... and there will probably be loads and loads of others in order that they are all detected immediately.”

These virus writers are getting trickier by the day

Cheers

 

Very interesting Blackspear! Thank you.

What does the X-Message-Info field in the email header refer to?
I have Thunderbird with lots of X- fields, but no X-Message-Info.
Do you think this is a buffer overflow type exploit?
Or maybe just trying to throw off AV that depend on that field for signature id? Maybe stronger signatures would help?

It is understandable performance wise why Eset would choose to not parse the text of each email. The biggest threat in emails is from the attachments after all. People foolish enough to have Javascript enabled on their email client would be vulnerable. Better to just use plain text with no scripting for safety.

But this leads me to the strong possibility that the IMON HTTP scanner also does not parse the HTML page. It would only scan for objects that get downloaded (embedded or otherwise). This would allow the scanning of the more dangerous objects like Java or Trojan droppers before they are actually executed (at least in active mode). It would be able to detect the malware before AMON would have to deal with it running in memory.
If this is the case, then the IMON HTTP scanner would NOT protect us from any of the Javascript trojans(whatever they are) or other Javascript exploits.

If this is the case, then the answer to my question is no, IMON does not pre-filter encoded characters because it doesn't process any characters at all. IMON HTTP scanning is a valuable addition to one's arsenal provided it is able to detect the trojans, keyloggers, and other malware that seems to be showing up on web pages these days.
That means for filtering malicious Javascript (including prefiltering encoded characters) one would require a web filter like Proxomitron. Hopefully there is a way to prefilter encoded characters in Proxomitron...

 

My pleasure

I think it was designed to bypass Anti-virus software…

The rest of your questions will require someone like Anders from Eset to answer them

Cheers

 

Should I email Anders or do you think he will visit here?

If by email, what is the right address?