To whom it may concern.
We've been testing the AMP feature on Cisco ESA.
Our testing results...
1) File upload limit.
Currently there is a file upload limit. This limit counts per 24 hours.
Model analysis_file_upload_threshold
C000V 10
C100V 100
C300V 300
C600V 600
C160 100
C170 150
C190 150
C360 200
C370 250
C380 450
C390 450
C660 500
C670 500
C680 1000
C690 1000
X1060 1000
X1070 1000
Once the limit has been reached, attachments with unknown verdict will no longer be uploaded to Cisco for analysis and bypass the AMP.
2) Attachment crashes scanning
When implementing an AMP demo for another customer we noticed that a winmail.dat attachment (a very common mail attachment container) crashes the scanning engines.
Example from the log:
Message 2031 encountered message scanning error: local variable 'tmp_file_path' referenced before assignment
This has been reported in defect CSCuy53537 (Corrupt attachments not getting detected and scanning error thrown).
This defect causes attachments to bypass the AV and content scanning!
When searching for the bug I still get "Insufficient Permissions to View Bug". I understand why....
3) winmail.dat content bypasses AMP
When testing we noticed that any malware in a winmail.dat container doesn't get scanned by AMP.
The Sophos engine does convert the contents and an Eicar sample was catched via Sophos but passed AMP.
So new malicious office/pdf documents simply can be send in a winmail.dat container and they won't be uploaded and the contents will not be scanned by AMP.
They simply test the hash of the .dat container instead of unpacking the content.
Content sent as winmail.dat:
Wed Mar 30 09:35:38 2016 Info: New SMTP ICID 8 interface Management (192.168.63.25) address 192.168.63.143 reverse dns host unknown verified no
Wed Mar 30 09:35:38 2016 Info: ICID 8 ACCEPT SG UNKNOWNLIST match sbrs[none] SBRS rfc1918
Wed Mar 30 09:35:38 2016 Info: Start MID 9 ICID 8
Wed Mar 30 09:35:38 2016 Info: MID 9 ICID 8 From: <***>
Wed Mar 30 09:35:38 2016 Info: MID 9 ICID 8 RID 0 To: <***>
Wed Mar 30 09:35:38 2016 Info: MID 9 Message-ID '<***>'
Wed Mar 30 09:35:38 2016 Info: MID 9 Subject 'Test 12'
Wed Mar 30 09:35:38 2016 Info: MID 9 ready 23660 bytes from <***>
Wed Mar 30 09:35:38 2016 Info: MID 9 attachment 'winmail.dat'
Wed Mar 30 09:35:38 2016 Info: MID 9 Custom Log Entry: FileTypes: application/octet-stream
Wed Mar 30 09:35:38 2016 Info: MID 9 Custom Log Entry: FileNames: winmail.dat
Wed Mar 30 09:35:38 2016 Info: MID 9 matched all recipients for per-recipient policy DEFAULT in the inbound table
Wed Mar 30 09:35:39 2016 Info: MID 9 interim verdict using engine: CASE spam negative
Wed Mar 30 09:35:39 2016 Info: MID 9 using engine: CASE spam negative
Wed Mar 30 09:35:39 2016 Info: MID 9 AMP file reputation verdict : CLEAN
Wed Mar 30 09:35:39 2016 Info: MID 9 Outbreak Filters: verdict negative
Wed Mar 30 09:35:39 2016 Info: MID 9 quarantined to "Policy" (content filter:quarantine)
Wed Mar 30 09:35:39 2016 Info: Message finished MID 9 done
Wed Mar 30 09:35:41 2016 Info: ICID 8 close
Same content sent as regular email:
Tue Mar 29 10:42:49 2016 Info: New SMTP ICID 7 interface Management (192.168.63.25) address 192.168.63.143 reverse dns host unknown verified no
Tue Mar 29 10:42:49 2016 Info: ICID 7 ACCEPT SG UNKNOWNLIST match sbrs[none] SBRS rfc1918
Tue Mar 29 10:42:49 2016 Info: Start MID 7 ICID 7
Tue Mar 29 10:42:49 2016 Info: MID 7 ICID 7 From: <***>
Tue Mar 29 10:42:49 2016 Info: MID 7 ICID 7 RID 0 To: <***>
Tue Mar 29 10:42:49 2016 Info: MID 7 Message-ID '<***>'
Tue Mar 29 10:42:49 2016 Info: MID 7 Subject 'test 11'
Tue Mar 29 10:42:49 2016 Info: MID 7 ready 2945 bytes from <***>
Tue Mar 29 10:42:49 2016 Info: MID 7 attachment 'eicar_com.zip'
Tue Mar 29 10:42:49 2016 Info: MID 7 attachment 'eicarcom2.zip'
Tue Mar 29 10:42:49 2016 Info: MID 7 Custom Log Entry: FileTypes: compressed/zip, compressed/zip
Tue Mar 29 10:42:49 2016 Info: MID 7 Custom Log Entry: FileNames: eicar_com.zip, eicarcom2.zip
Tue Mar 29 10:42:49 2016 Info: MID 7 matched all recipients for per-recipient policy DEFAULT in the inbound table
Tue Mar 29 10:42:49 2016 Info: MID 7 interim verdict using engine: CASE spam negative
Tue Mar 29 10:42:49 2016 Info: MID 7 using engine: CASE spam negative
Tue Mar 29 10:42:49 2016 Info: MID 7 AMP file reputation verdict : MALWARE
Tue Mar 29 10:42:49 2016 Info: MID 7 rewritten to MID 8 by AMP
Tue Mar 29 10:42:49 2016 Info: Start MID 8 ICID 0
Tue Mar 29 10:42:49 2016 Info: MID 8 ICID 0 From: <***>
Tue Mar 29 10:42:49 2016 Info: MID 8 ICID 0 RID 0 To: <***>
Tue Mar 29 10:42:49 2016 Info: Message finished MID 7 done
Tue Mar 29 10:42:49 2016 Info: Message aborted MID 8 Dropped by amp
Tue Mar 29 10:42:49 2016 Info: Message finished MID 8 done
Tue Mar 29 10:42:51 2016 Info: ICID 7 close
Problem is that Exchange automatically converts the winmail.dat back to regular attachments so the end user won't notice the difference.
Reply from Cisco Support:
The AMP cloud is designed to track all SHA256 hashes as well as their associated dispositions.
The AMP implementations in our products are specifically looking at the file magic/types that present risk,
and that we can reliably inspect. DAT files regardless of commonality, are not one of the primary file types that we inspect because it is generic.
This file type could be leveraged any number of ways, encoded, encrypted, abstracted, and is contextual with respect to the parent application.
There is no consistent mechanism to inspect this as something standardized like ZIP.
Additionally, DAT files will not be directly executable, which is why sandbox runs will fail for these types.
So they clearly don't understand our concern and the winmail.dat story.
Besides this it does seem to do the job... :-)
regards,
