Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 27 replies
  • Answers 2 answers
  • Subscribers 50 subscribers
  • Views 7321 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

FFin

Hi, 

are SOFS and SG UTM affected by CVE-2023-51766 (Sender Spoofing by SMTP)?



This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to Seth Bodine

    Regardless of the investigation of Sophos (DEV) i took a look at your code  . 
    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?

    __________________________________________________________________________________________________________________

Children
  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to Seth Bodine

    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).

  • 0 in reply to Seth Bodine

    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 

    __________________________________________________________________________________________________________________

  • +1 in reply to Seth Bodine

    Hi Seth! Daniel here, an engineer from the email team at Sophos.

    Based on the information provided I can't confirm that you induced SMTP smuggling. You say the following:

    "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."

    The point of the exploit as explained in the CCC webinar is that the smuggled emails bypass the SPF check because it only checks the first email. In your case, SPF checks run for every domain and as you say, block them. 

    Another thing that can cause confusion is softfail: SPF checks can result in softfail if the SPF record is created with "~all" instead of "-all". SFOS doesn't block this result, so it can seem as if the SPF check didn't work or smuggling was successful. 

    Nevertheless, I would be happy to investigate further if you provide me with an access ID and logs of the issue happening. If SMTP and exim debug logs are enabled it will be quite easy to see if the exploit worked or not.

  • 0 in reply to Dániel Lengyel

    Happy to provide further information let me know what log files you need, and any changes to initate debug logs.

  • 0 in reply to Seth Bodine

    Can you share (via PM) your Examples, you used for the PoC Code? So we can reproduce it? 

    __________________________________________________________________________________________________________________

  • 0 in reply to Seth Bodine

    Hi Seth!

    Here's how you can help:

    1. Give me an access ID to your system like so: https://doc.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Diagnostics/ConnectionList/SupportAccess/index.html
      This is just so I can check out your configuration. (You might not be able to do this. In that case, you could send me screenshots of the Policies & exceptions section of your SFOS Email page, as well all the policies and exceptions you have configured.)
    2. Run another test and collect debug logs. You can do this like so:
      1. Get everything set so all you have to do is send the email.
      2. In the admin console, write the following commands:
        1. service -ds nosync smtpd:debug
        2. service -ds nosync smtpd:exim_debug
      3. Attempt to send the smuggled mail.
      4. Run the same commands as before so your logs won't continue to fill with debug lines.
      5. Send over smtpd_main.log found in /log

    You can send everything over in a private message.

    Also: please remember to turn on SPF for testing. If the smuggled mail can't bypass SPF, then it isn't a case of SMTP smuggling.

Unfiltered HTML