|
Vulnerability InterScan VirusWall Affected Trend Micro's InterScan VirusWall version 3.0.1 for Solaris. Description Following is based on Alcatel Security Advisory. The NewApt Worm is currently exploiting this bug to avoid detection. By sending an SMTP message with a malformed attachment, it is possible for malicious code to avoid detection by Trend Micro's InterScan SMTP scanner version 3.0.1 for Solaris. Other versions may be affected as well, but were not tested. RFC2045 describes the number of padding characters needed at the end of a base64 encoded MIME attachment. InterScan VirusWall does not properly handle incorrectly padded attachments. Upon receiving such an attachment, InterScan fails to scan the attachment properly and the message is allowed to pass through; however, InterScan does log the following message to its system logs: base64: Unexpected EOF seen Note: This modification of the padding does not appear to affect mail clients such as Netscape Communicator. Alcatel noticed this bug while testing the product with live viruses. The NewApt Worm replicates by replying to emails in the victim's mailbox. The above error message was a clear indication that this particular attachment was problematic. It was determined that an extra "=" character at the end of the base64 encoding was the cause of the problem. Further investigation revealed that if the correct number of "=" characters (as per RFC2045) were not present, InterScan failed to catch the virus. This was tested with several other viruses such as Melissa and Shankar. To exploit this vulnerability, create a new message with the virus of your choice attached. Save this message to your local disk. Edit the message and add any number of "=" characters to the end of the base64 encoded attachment. This message will now pass through the InterScan VirusWall, and the virus will remain undetected and intact. John Lampe added following. Along a similar vein numbers 1 through 3 below will also allow virus-infected attachements to pass right by Interscan Viruswall. 1) adding a "-" to the end of base64 message 2)changing content-type application type in the header Example, Content-type: Application/FOO; name="whatever.doc" 3) Adding an extra "-" at end of base64 boundary 3 methods above were tested and verified on NT running the latest engine from Trend Micro, along with the latest patch. At least one of the methods above (Number 1) was tested and verified on a Solaris box by Kris Herrin (the original poster). 3 methods above were chosen *at random* from RFC 2045. Vendor was notified. Solution Trend Micro has posted a fix for this bug. The patch is can be downloaded from the following URL: http://www.antivirus.com/download/patches.htm The patch is titled isvwsol301a_u2.tar.