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

'Lockdown' exploit prevented in Internet Explorer accessing Sharepoint site?

We have a couple of computers that are being blocked from a Sharepoint site with the Sophos message "'Lockdown' exploit prevented in Internet Explorer". These computers were able to access the same site yesterday. There were six Windows patches installed last night that may be contributing as some other computers where the patches haven't installed aren't experiencing the "'Lockdown' exploit prevented in Internet Explorer" block when getting to the exact same Sharepoint site.

These are the patches that were installed:

  • Cumulative security update for Internet Explorer: February 13, 2018 (KB4074736)
  • 2018-02 Security Only Quality Update for Windows 7 for x64-based Systems (KB4074587)
  • 2018-02 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB4074598)
  • Security Update for Microsoft Office 2010 (KB4011707) 32-Bit Edition
  • Security Update for Microsoft Office 2010 (KB3114874) 32-Bit Edition
  • Security Update for Microsoft Outlook 2010 (KB4011711) 32-Bit Edition

I'm wondering if anyone else has encountered any issues with these patches in relation to Sharepoint and Sophos.



This thread was automatically locked due to age.
  • Timothy Frazier said:

    I've encountered this a few times on different sites within the past week or so.  I've just been adding a global exception but if it keeps reoccuring for different sites that are legitimate, it'll become a nuisance.  Has anyone that submitted a ticket heard back from support? 

     

    I've submitted a ticket with a pretty good description of the issue along with the SDU dump. I'm still waiting for them to analyze it and get back to me. 

  • Just had a report of this from a user, on a client's share point portal when attempting to upload files, kinda don't wan to add the exploit exclusion if this is a false positive.

    User's are going to attempt to use Chrome as the client need their files.

  • I had sophos call me on this and a woman that spoke broken english claimed she was going to send an email  w/ instructions on collecting logs etc, and what was 2 days ago.  Sopshos isn't impressing me w/ this. 

  • Hi Greg,

    We deployed the same security updates you listed to our Win 7 machines on 2/22/18.  Then started to see the "Lockdown" events on 2/23/18.  What's triggering it for our users are certain finance websites.  Some of the sites require compatibility view mode enabled.  Don't know if that is causing it as well.  I opened a support ticket so hope we see a resolution soon.  But in the meantime I added Internet Explorer to the Exploit Mitigation exclusion so our users can get their work done.

     

    Greg Francis said:

    We have a couple of computers that are being blocked from a Sharepoint site with the Sophos message "'Lockdown' exploit prevented in Internet Explorer". These computers were able to access the same site yesterday. There were six Windows patches installed last night that may be contributing as some other computers where the patches haven't installed aren't experiencing the "'Lockdown' exploit prevented in Internet Explorer" block when getting to the exact same Sharepoint site.

    These are the patches that were installed:

    • Cumulative security update for Internet Explorer: February 13, 2018 (KB4074736)
    • 2018-02 Security Only Quality Update for Windows 7 for x64-based Systems (KB4074587)
    • 2018-02 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB4074598)
    • Security Update for Microsoft Office 2010 (KB4011707) 32-Bit Edition
    • Security Update for Microsoft Office 2010 (KB3114874) 32-Bit Edition
    • Security Update for Microsoft Outlook 2010 (KB4011711) 32-Bit Edition

    I'm wondering if anyone else has encountered any issues with these patches in relation to Sharepoint and Sophos.

     

  • Hi Wing

    I have encountered the same issue since installing Sophos and also those patches for financial websites

    I've had to add them to the Global Exclusion list but where it is annoying is that one of our users is accessing certain parts of the web page he keeps getting blocked at each bit. Does anyone know of a way to add the whole site to the Exclusion list? Rather than page by page

  • I think you may need to add Internet Explorer entirely as an exclusion until this can get resolved.

  • In the Exploit Mitigation Exclusions I added Internet Explorer as the Excluded Application.

  • We are also experiencing this issue since deploying February's MS Patches - not with accessing Sharepoint site but with a handful of other business required websites.

    We've had to add Internet Explorer to the Global Exception list until Sophos fix the issue [not ideal].

    I've logged a call with Sophos, waiting to hear back from them...

  • I've been working with Sophos support on this issue for the past couple of weeks as we still don't have a specific resolution at this time. The issue that we see is that sites in question are invoking "VBScript God Mode."

    Here's the most recent information I have from Sophos Support:

    ----

    Mitigation   Lockdown

    Platform     6.1.7601/x64 v731 06_3a
    PID          11124
    Application  C:\Program Files (x86)\Internet Explorer\iexplore.exe
    Description  Internet Explorer 11

    VBScript God Mode

     

    ... Specific details from our Event Log deleted ...

     

    It should not be allowed as an exploit, as there is no reason to trigger this outside an exploit scenario. It uses an array allocation issue to break out of VBscripts sandbox in the browser and access the full operating system without any protections.

    Page 8 of our Exploit's Explained guide discusses this vulnerability:


    secure2.sophos.com/.../Comprehensive-Exploit-Prevention.pdf

    VBScript God Mode On Windows:


    VBScript can be used in browsers or the local shell. When used in the browser, the abilities of VBScript are restricted for security reasons. This restriction is controlled by the safemode flag. If this flag is modified, VBScript in HTML can do everything as though it’s in the local shell. Consequently, attackers can easily write malicious code in VBScript. Manipulating the safemode flag on VBScript in the web browser is known as God Mode3. As an example, an attacker can modify the safemode flag value by leveraging the CVE- 2014-6332 vulnerability4, a bug caused by improper handling while resizing an array in the Internet Explorer VBScript engine. In God Mode, arbitrary code written in VBScript can break out of the browser sandbox. Thanks to God Mode, data execution prevention (DEP), address space layout randomization (ASLR), and control-flow guard (CFG) protections are not in play. Vendors supporting this mitigation technique: Sophos Intercept X, Microsoft EMET, Malwarebytes Anti-Exploit

    It is not recommended to exclude this, but to have the vendor look at their code, as this is a very well-known vulnerability, and very difficult to trigger by accident.

    In any-case, the it's not scripted as God Mode as such, but as 'Safe Mode flag' (CVE-2016-6332). By default, the usage of VBScript functionality in browsers is restricted. This restriction is a controlled by ‘safemode’ flag. The default value of ‘safemode’ flag is always ‘0xE’. If the default value of ‘safemode’ flag is changed then using VBScript, malicious activity can be performed. Controlling of ‘safemode’ flag using VBScript in web browsers has been called ‘GodMode’. Thus, this exploit is famously known as ‘GodMode’ exploit.

    As I mentioned above, we do not recommend setting up exclusions to get around these exploits, however here are some workaround options you could implement (in order of most to least preffered), until this is resolved in the website code:

    1-The best option would be to exclude the detected exploits, Lockdown in this case. This is the recommended way to implement an exploit exclusion, however in this case it may not be feasible. The reason I say this is, in this case the Sophos identifier for each detection ( called a Thumbprint) is different on each URL visited. So, if these full URLs would change often, you would need to do another exclusion often as well. If however, you only have the few URLs that you access than this would be the best way to go.

    2-Excluding Web browsers in the Threat policy, Settings under Mitigate exploits in vulnerable applications, un-check Protect Web Browsers. This can be implemented in a policy that triggers only specific users.

    3-The other option, that is a global setting affecting all your users, is to exclude the browser processes via: System Settings -> General Settings -> Exploit Mitigation Exclusions

    Turn off Compatibility mode

    Step 1:

    For IE 10 users:

    Open up Internet Explorer (IE 10)

    Click on the Tools menu tab

    Select the Compatibility View settings option

    For IE 11 users:

    Open up Internet Explorer (IE 11)

    Press the Alt key on your keyboard, this will make a menu bar appear

    Click on the Tools menu tab

    Select the Compatibility View settings option

    Step 2:

    If you are using IE 10, you will get the following "Compatibility View Setting" page

    Uncheck the "Display all websites in Compatibility View" option

    Uncheck the "Display intranet sites in Compatibility View" option

    Do not add GMS or Analyzer URL to the Compatibility View box

    If you are using IE 11, you will get the following "Compatibility View Setting" page

    In IE 11, the  "Display all websites in Compatibility View" option is not available

    Uncheck the "Display intranet sites in Compatibility View" option

    Do not add GMS or Analyzer URL to the Compatibility View box

    So with this issue, adding the URL experiencing the lockdown exploit to IE’s Trusted Sites in Internet Options is a viable option in helping to resolve and allow access to this particular site. Scanning will continue however and anything outside of these that triggers an alert will be flagged.

    There is a fix on the horizon as this does only effect IE as far as we can tell, and mainly only Windows 10 computers. The fix from what I have been told by our GES / Development team is due out in Q2 -2018, as they have to write additional code to address this.

    As for the fix you have in place, this can be continued to be used safely at this stage, and is approved by our Development team.

    ----