3CX DLL-Sideloading attack: What you need to know
Soft Release 9.400-9
Have turned on Sandstorm for Email, and just received one that had been classified as Clean. Unfortunately the received email had lots of the headers appearing in the body section, and the files were shown as text in the email, rather than as attachments:
Received: from astaro1.bordo.com.au (localhost [127.0.0.1])
by mail.bordo.com.au (Postfix) with ESMTPS id 1EF216CE99B5
for <email@example.com>; Fri, 8 Apr 2016 11:22:11 +1000 (EST)
Received: from unknown ([192.168.1.2] helo=astaro1.bordo.com.au) by
mail.bordo.com.au with SMTP (2.5.2); 8 Apr 2016 11:22:10 +1000
Received: from staff.icp-osb-irony-out6.external.iinet.net.au ([18.104.22.168]:53490)
by astaro1.bordo.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX)
for firstname.lastname@example.org; Fri, 08 Apr 2016 11:20:00 +1000
Received: from unknown (HELO IEP-OSB-EGAMSG1) ([22.214.171.124])
by icp-osb-irony-out6.iinet.net.au with ESMTP; 08 Apr 2016 09:19:48 +0800
Date: Fri, 8 Apr 2016 09:19:48 +0800 (WST)
From: iiNet Billing Team <email@example.com>
Subject: iiNet Invoice: #77038926
X-Mailer: PBBI e-Messaging Solution
--- Sandbox result ---
--- Sandbox result end ---
X-Assp-ID: mail.bordo.com.au id-78530-11079
X-Assp-Session: 7F849D967740 (mail 1)
X-Assp-Version: 2.5.2(16097) on mail.bordo.com.au
X-Assp-Whitelisted: Yes (whitelistdb)
Content-Type: text/html; charset=UTF-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- DOC1 Generate Build=6.0.1978.0 Date=08-04-2016 Time=09:19:43 Platform=Microsoft Windows -->
<!-- 15582C5AD5A75443A821F709D7D5F039 -->
<body bgcolor="#FFFFFF" link="#0000FF" alink="#FF0000" vlink="#AAAAAA"><table align="CENTER"><tr><td>
<table width=717 cellpadding=0 cellspacing=0 border=0><tr valign=top>
<td width=38 height=19 bgcolor="#F0F0F0">
<td width=643 height=19 bgcolor="#F0F0F0">
Is the problem that a new line was put before "--- Sandbox result ---"?
(Also, none of the Email files get listed in the Sandbox Activity section).
The problem is indeed with the empty line before the Sandbox result, however it only appears when the mail's Content-Type is text/plain - which shouldn't be possible if it contains an attachment. So actually I'm quite puzzled as to how this happened, I will open a ticket for this problem nevertheless.
As for Email files not being listed on the Sandbox Activity page, please see this topic.
We run an anti-spam system on our mail server and I asked the developer about this. He replied:
IMHO this part is wrong:x-references: firstname.lastname@example.orgC5AD5A75443A821F709D7D5F039--- Sandbox result ---2efed5f8-e490-4c34-80c0-bdf3a1a61e4b invoice_77038926.pdf--- Sandbox result end ---original text may look as followsx-references: email@example.comC5AD5A75443A821F709D7D5F039--- Sandbox result ---2efed5f8-e490-4c34-80c0-bdf3a1a61e4b invoice_77038926.pdf--- Sandbox result end ---but even this is wrong because line 2 to 4 must be intented if they are related to 'x-references'If they are not related to this headerline - they are absolutely wrong and may misinterpreted by the mail server and/or client as boundary.Whitespaces are not allowed in headertag names.An headertag name has to be terminated by ':'Continued header lines have to be intended by one single SPACE or TAB.RAW whitespaces are not allowed in boundary definition - boundary definitions with whitespaces have to be double quoted..These are some simple rules for MIME header lines. Looking at the three lines added by sophos, they are wrong in every case - for what ever they are used in therms of MIME.
Don't know if this helps.
According to RFC2822, section 3.5 the first line containing only CRLF marks the boundary between the header and the body section.
As such, this was clearly a bug on our side, that whole result section shouldn't have been included in the delivered mail in the first place. This behavior was obscured by the fact that since the 'Sandbox result' part is appended to the end of the header section which contains a 'Content-Type: multipart/...' header since the mail has at least one attachment that was sent for Sandstorm scanning: The 'Sandbox result' part is treated as the beginning of the body, however as it is placed before the first MIME boundary (the beginning of the original body), it isn't displayed. In your case however, as the topmost Content-Type is text/plain, the 'Sandbox result' improperly (or rather, properly :) ) acts as the beginning of the mail body.
You can expect a fix to this issue soon.
Great. Will look forward to the fix.
I upgraded to version 9.401-11 last night, but this morning a user received an email that had been 'butchered' by Sandstorm:
Subject: Your new Telstra bill for account 2202351601232 is attachedMessage-ID: <firstname.lastname@example.org>Date: Thu, 14 Apr 2016 08:21:12 +1000
--- Sandbox result ---d8fb6a59-082a-4d83-932b-8abb91bc013a TRPB_1_1147190156.pdf--- Sandbox result end ---MIME-Version: 1.0Content-Type: multipart/mixed; boundary="Boundary.1460586043"
So I suppose the fix didn't make it into this update?
Unfortunately, 9.401 was already into testing by the time this error was located and fixed, so it will only be included in 9.402. Sorry about the inconvenience... :(