UTM Vulnerable to clickjacking

Hey All,

I have a weird one.

We have 2 UTMs, both running 9.705-3 doing WAF for Exchange Server deployed per the KB - https://support.sophos.com/support/s/article/KB-000038003?language=en_US

Everything is working fine, but we are renewing our annual security test including a PenTest
One of these is showing as vulnerable to clickjacking and one is not

I have gone through the config side by side and both look identical, i cant figure it out. 

The links offered up by the PenTest software are: 


But i can't find a way to insert these headers. 

If i test with https://www.lookout.net/test/clickjack.html one does load the page (which it shouldn't) and one does not load the page denying the connection (which should be the behaviour) so something isn't set correctly, its just where to change it

Can anyone shove me in the right direction?

Added line about testing
[edited by: vAdmin at 11:16 AM (GMT -7) on 3 May 2021]
  • Hi ,

    Thanks for reaching out to the Community! 

    I would suggest you check if there's any DNAT rule for the service/port that got detected in the scan. 



    Harsh Patel (H_Patel)

    Community Support Engineer | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' button.

  • No DNAT on the UTM and I can see that the UTM is responding as there are the other headers added by the UTM present 

    In both instances it is acting as a WAF only. 

  • Hi and welcome to the UTM Community!

    Standard questions:  On the one working correctly, do you see the block in the WAF log or in the Intrusion Prevention log?  Have you tried restoring a recent config backup on the bad guy? Have you tried re-booting?

    Cheers - Bob

    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • There is no block happening, and that is the problem. 

    I have not tried a reboot or a config restoration. I did restart apache however, no dice. 

  • Where is the block in the unit that behaves correctly?  This will be a clue to avoid the following...

    My usual suggestion would be to try the following, in order, on the misbehaving unit until the problem disappears:

    1. Restore a config backup.
    2. Reboot.
    3. Re-image from ISO and restore.

    Any luck with that?

    Cheers - Bob

    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Ok, so I completely pulled this apart over the last 24 hours and worked out that i was / the tool I'm using is wrong. 

    BOTH are vulnerable to clickjacking and found a better tool to actually test it https://clickjacker.io/ 

    So I'm back at square one which is that I need the WAF module to be able to inject one of those options in the headers. 
    The login form will offer some limited protection to one of our applications but we have a couple things that pass to embedded webservers that we can't modify

    So I guess this comes down to how can we do custom apache config to add those headers at the CLI through an inclusions line? 
    There is a good summary of fixes here https://clickjacker.io/how-to-fix-clickjacking 

    Or if anyone has any other ideas I would really appreciate them 

  • Ok, found it after stitching together multiple other threads on the topic. 

    Secondly: THIS IS NOT A SUPPORTED CONFIG. You will be making backend changes and if you don't know what you are doing, bail out now
    Thirdly: It is likely to be reset upon a webUI change, firmware upgrade or reboot of the device. You will need to recheck on both of these conditions to ensure it remains in place

    Also, just because you patch the Sophos unit doesn't solve your issue. These headers also need to be set on the backend servers (aka the "real webservers"). 

    Take a backup of your ENTIRE config before proceeding. 

    Edit: /var/storage/chroot-reverseproxy/usr/apache/conf/reverseproxy.conf 
    Under each VHost you want to fix, find this line: RequestHeader set X-Forwarded-Proto https

    Directly under that line without amending it, add these lines:
    Header always set X-Frame-Options "DENY"
    Header always set Content-Security-Policy "frame-ancestors 'none'"

    Save the file

    Restart the service by running:     /var/mdw/scripts/reverseproxy restart

    You can also insert the lines to  /var/storage/chroot-reverseproxy/usr/apache/conf/httpd.conf  to do global protection if you were so keen. 

    Retest your config to ensure everything works as expected


    Profit! / Go to the pub

  • Just realized you're new here.  Your first thread and you have the class to share what you worked hard alone to discover.  

    Glad to have you here in the UTM Community!

    Cheers - Bob

    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA