SFOS and SG UTM affected by SMTP/EXIM CVE-2023-51766?

Hello there,

Thank you for contacting the Sophos Community.

I need to reach out internally to confirm; I will update the post once I hear back or by the end of the day on Tuesday.

Regards,

 emmosophos Do you have details for us regarding the Exim vulnerability  CVE-2023-51766 and it's impact on the current versions of XG/UTM ?

Hello,

I am still waiting for confirmation on this from the security team. I am expecting to hear back tomorrow or the day after (the latest).

Regards,

I can confirm that the UTM9 vm is vaulnerable to this - have seen some odd behavious with some stuffed emails failing SPF checks, which results in any further items failing.

Hi wlogic & FFin  The development review related to CVE 2023-51766 is completed for XG and UTM both OSes and below is the update from the Dev team.

Although both systems use the affected Exim version 4.96, this vulnerability does not affect them. This is because CHUNKING is disabled by default on XG and UTM.

Please refer to this URL for more info - github.com/.../cve-2023-51766

I can provide logs that show that inbound smuggled emails are being processed, and that there is an issue with UTM

Sure if you can share the logs and a sample smuggled email, that would be helpful. If you can share your exim.conf file that would be even better. 

We tested & reproduced the smtp smuggling vulnerability, and confirmed on both SFOS & UTM with default configuration (chunking disabled) they're safe. 

Hello,

Adding to what Bobby mentioned, please open a case with Support, submit the Samples and share the Case ID. 

You can find the exim.conf file in the following path # cat /var/storage/chroot-smtp/etc/exim.conf 

Regards,

Are you sure, you are not using a Header From Spoof attack, which UTM does not cover? 

Are you sure, you are not using a Header From Spoof attack, which UTM does not cover? 

I don't think so, this was smuggling

poc payload looks something like this

send: sending "From: test@[valid domain #1]co.nz\r" to { exp4 }
send: sending "To: validrecipient@[valid domain #2].co.nz\r" to { exp4 }
send: sending "Subject: 1st email\r" to { exp4 }
send: sending "\r" to { exp4 }
send: sending "1st email content with many others emails\r" to { exp4 }
send: sending "\r" to { exp4 }
send: sending ".\r" to { exp4 }
send: sending "mail FROM:<spoofedvalidrecipient#1@[invalid domain #1].co.nz>\r" to { exp4 }
send: sending "rcpt TO:<validrecipient#1@[valid domain #2].co.nz>\r" to { exp4 }
send: sending "data\r" to { exp4 }
send: sending "From: spoofedvalidrecipient#1@[invalid domain #1].co.nz\r" to { exp4 }
send: sending "To: validrecipient#1@[valid domain #2].co.nz\r" to { exp4 }
send: sending "Subject: Spoofed email #1\r" to { exp4 }
send: sending "\r" to { exp4 }
send: sending "Content of the #1 spoofed email\r" to { exp4 }
send: sending "\r" to { exp4 }
send: sending ".\r" to { exp4 }

poc code (modified) can be found here CVE-2023-51764.sh

Hello,

As mentioned if you want this to be investigated further, please submit the original logs along with your exim.conf file.

Regards,

Home user - waiting on support account to be registered. before providing logs.

Hi,

you won't get a support account created as a home user. You might be able to send them to Emmanuel to forward to the support team.

Ian

Eh - gave up mucking about with raising a support ticket... have emailed security-alert@sophos.com (as per security.txt) - it'll either be fixed, or ignored. So we'll see in 87(90-3) days...

Thank you for the details Seth, I'll get our engineering team to look into this further. 

Regardless of the investigation of Sophos (DEV) i took a look at your code Seth Bodine . 
My SFOS appliances does block the second email with SPF sent by the CVE code. 
What did you use as a Spoof Email? Because my Email has a valid SPF Record first and then the second (spoof) email is a SPF Hardfail Email - Which gets blocked. 

I could see individual SPF checks for each mail based on the Email CVE script. 

What kind of examples did you use Seth?

Hey LuCar

if valid SPF exists it can impact the smuggling of the emails, however, if you were to disable SPF for the originating sender IP it should then process fine.

for the main email I picked an external domain at random that didn't have SPF records, for the smuggled emails I used my own domains where SPF, DKIM and DMARC were configured and enforced. so disabling SPF for the originating IP resulted in all emails being smuggled.

From what I saw, DKIM and DMARC were ignored for the smuggled emails, and SPF checks were executed, and failed as the external IP was not permitted to send email.

hope that helps.

one correction, I suspect that my UTM may have validated SPF against itself for the smuggled emails - but I didn't dig into this further at the time (apologies fror any confusion).

Could you send me via PM the POC Code you used? 
Because as far as i understand you, i should be able to reproduce it with your exact examples: one non existing Email and a SPF record from you. 

I was watching the entire CCC webinar and checked for the logic behind this attack and from what i could see, SFOS and UTM did a SPF check for each indiviual Email generated by this PoC code: https://github.com/duy-31/CVE-2023-51764/ So as soon as SFOS / UTM threats those emails individually (and check for SPF) it should not be affected (by my understanding). 

See: https://youtu.be/V8KPV96g1To