Woody Leonhard's no-bull news, tips and help for Windows, Office and more… Please disable your ad blocker – our (polite!) ads help keep AskWoody going!
Home icon Home icon Home icon Email icon RSS icon
  • Patch Lady: Tracking some post release issues

    Posted on March 14th, 2018 at 02:04 Susan Bradley Comment on the AskWoody Lounge

    Update:  Mark Berry has an excellent blog post about how to do a group policy update on the network as well a warning about not setting that value too soon!

    Susan here with early reports from the Tuesday releases (or Wednesday depending on your time zone).  Normally we don’t start seeing issues until tomorrow but already we have a few issues bubbling up.  This issue is actually expected and you’ll need to look for updates for any third party remote desktop software that may be impacted.  The reason for this is a major change in the Credential security support provider.  You’ll probably see this in the news talked about as the CredSSP issue.  In the security portal the issue is called out here:

    To be fully protected against CVE-2018-0886, users must enable Group Policy settings on their systems and update their Remote Desktop clients. The Group Policy settings are disabled by default to prevent connectivity problems and users must follow the instructions documented HERE to be fully protected.

    But I’ll be flat honest, I missed it upon first reviewing the security portal and didn’t realize the impact until later.

    The issue impacts remote desktop protocol. If you’ve ever launched the remote desktop connection application on any of your Windows computers, you’ve used CredSSP in your use to remote into computers.

    The flaw will be demonstrated next week at a BlackHat conference, but that said you can tell from the description that this will be difficult to exploit in a consumer setting:

    Exploiting the flaw requires the attacker to wage a man-in-the-middle attack between the client and server in an RDP or WinRM session. He or she would need WiFi or physical access to the targeted network. A WiFi exploit could be set up using a key reinstallation attack such as KRACK, for example, according to the researchers. Other vectors are Address Resolution Protocol (ARP) poisoning and exploiting vulnerable network devices such as routers, to reach servers inside.

    The security fix is actually going to be phased in over the next several months. This month (as per Microsoft) is phase one.  All supported workstations and servers will get the update this month, next month in April, Microsoft will start phasing in error messages if you rdp from a patched client into an unpatched server and finally in May the registry setting to better protect servers from unpatched system will kick in.

    Bleeping computer even has a video that the researchers have shared discussing the flaw and it’s impact. As is noted, attackers have to have a toe hold into your network before this can be successful, they would have to do a Man in the middle attack to intercept your rdp transmission.  In a peer to peer network that would mean they’d have to have malicious code and be in your router.  Given the complexity, time spent to craft the packets just so, this one is more in the “they really have to target you” and not in what I call “roadkill” variety of vulnerabilities.

    It impacts ALL versions of supported windows, so for anyone in businesses still using Windows XP, and relying on remote desktop protocol, just be aware that this may impact interaction between the platforms as these adjustments roll out over the next several months.

    Initially in March, they are rolling out the new protocol.  Later in April they will make it so that an error message will occur when you attempt to remote from a patched machine to an unpatched machine, and then later in May (tentative at this time) the default will be to enforce that remoting from a patched machine to an unpatched machine will not work.

    If you still need to go between patched and unpatched after May security updates come out, you’ll have to make a manual registry adjustment to lower the security of your system.  Hopefully no one has to do that.

    Consumer recommendations:  

    Actions needed:  Patch [after we wait a bit just to make sure it’s all clear for any other issues]

    I’ve not seen any side effects on Windows machines at this time.  I’ve even patched a workstation and left another workstation unpatched to see if there was any issues.  I personally saw none.  I have seen reports of issues where after installing the update on the Windows based machine, folks couldn’t use the RDP client on a Mac to remote into the Windows machine.  So on a consumer machines, if you only RDP between Windows machines you should be fine.  For a mixed network with Macs or other non Windows machines that use RDP protocol, check with your vendors for updates.

    In May the setting to set the protocol so that clients can’t fall back to using insecure versions of the CredSSP will kick in and thus there is no other action you need to do on standalone peer to peer networks other than to make sure that if you use RDP to remote into computers that all of your remoting still works after you apply the updates.

     

    Mitigated

    1

    Client applications that use CredSSP will not be able to fall back to insecure versions. Services that use CredSSP will accept unpatched clients.

    Domain/Network recommendations:

    If you are in a domain setting whereby you connect to a file server (not peer to peer), but something called a domain controller, here’s where the guidance differs as Microsoft recommends you roll these settings out now.  You actually need to set registry keys or group policy settings to allow for the phase in of this update.

    You can make the registry change/group policy in advance before you roll out the updates.

    In a Windows 10 Pro – when you go into edit group policy you can see the setting there.

    Double click to enable it and then set it to the value of Mitigated.  “Mitigated” whereby “Client applications that use CredSSP will not be able to fall back to insecure versions” will be the default value in May.

    Test.  See if anything breaks.  If it does, set it to vulnerable and then go see about getting an update to the RDP client that doesn’t work.

    Microsoft has stated that

    We recommend that administrators apply the policy and set it to  “Force updated clients” or “Mitigated” on client and server computers as soon as possible.  These changes will require a reboot of the affected systems.

    Hopefully I’ve made this a bit more clearer?  I’ll be working on updating the master patch listing for March and will post it Wednesday and will keep an eye out for any other issues along the way.

    If that helped, take a second to support AskWoody on Patreon

    Home Forums Patch Lady: Tracking some post release issues

    This topic contains 18 replies, has 11 voices, and was last updated by  columbia2011 5 months, 2 weeks ago.

    • Author
      Posts
    • #175452 Reply

      Susan Bradley
      AskWoody MVP

      Susan here with early reports from the Tuesday releases (or Wednesday depending on your time zone).  Normally we don’t start seeing issues until tomor
      [See the full post at: Patch Lady: Tracking some post release issues]

      Susan Bradley Patch Lady

      8 users thanked author for this post.
    • #175532 Reply

      MattB
      AskWoody Lounger

      We experienced some odd issues this morning on a handful of Windows 7 Pro systems – for some reason about half a dozen systems changed from static IP to DHCP.  Not sure if this is due to a patch or something else, but the timing is coincidental.

      1 user thanked author for this post.
    • #175540 Reply

      Mr. Natural
      AskWoody Lounger

      Sorry if I overlooked something mentioned in your article. Do the new patches introduce this group policy setting? We run Server 2012r2 DC’s with updated admx file to include Windows 10 policy settings and currently don’t see that encryption oracle remediation registry key. I use a Windows 10 1709 16299.192 on my main work pc and don’t see that group policy setting on my pc either.

      Thanks so much folks for all you do.

      1 user thanked author for this post.
      • #175683 Reply

        anonymous

        On a machine with latest updates installed, you need to copy credssp.amd{x,l} files from %WinDir%\PolicyDefinitions to your SYSVOL.

        1 user thanked author for this post.
      • #175784 Reply

        Susan Bradley
        AskWoody MVP

        You would need to grab a new admx file from a workstation and stick it up on the server.

        Actually read the better answer just above mine.

        Susan Bradley Patch Lady

        • This reply was modified 7 months, 1 week ago by  Susan Bradley.
        1 user thanked author for this post.
      • #175965 Reply

        mcbsys
        AskWoody Lounger

        Took me a bit to figure this out as well. Here’s what I came up with:

        https://www.mcbsys.com/blog/2018/03/updating-the-credssp-group-policy/

        • This reply was modified 7 months, 1 week ago by  mcbsys.
        1 user thanked author for this post.
    • #175549 Reply

      anonymous

      Will this affect (now or in three months’ time) the use of XPM (“pre-installed XP SP3”) in Win7 — which seems to use something like remote desktop functionality? Any guesses? I have an experimental Win7 machine installing the March Win7 security and IE11 updates now, to test this month’s status.

      Update: as at today (Win7 as updated with KB4088878 and KB4089187), the XPM window displays correctly and the (few) applications which I want to run there seem to be ok.  FYI, my XPM VM is not internet-facing, so I cannot vouch for behaviour in network tasks.

      HMcF

      1 user thanked author for this post.
      • #191161 Reply

        anonymous

        Update from HMcF:  on the experimental machine (Win7 Pro x64), as at May 9, with the Win7 host updated with KB4103712, the XPM environment still works / displays the XP screen / runs the (few) applications which I still need there, not bashed by any issues of Remote protocols.

        HMcF

    • #175579 Reply

      MrBrian
      AskWoody MVP
    • #175585 Reply

      MrBrian
      AskWoody MVP

      From Microsoft Remote Access Protocol Flaw Affects All Windows Machines: ‘”Exploiting the vulnerability was very difficult,” notes Zinar. “There were a lot of constraints about which packets we could use, and which certs we could use.”‘ Perhaps that’s why Microsoft rates this vulnerability’s exploitability assessment as “Exploitation Less Likely.”

    • #175591 Reply

      Metanis
      AskWoody Lounger

      I seem to be unable to find any info on what specific version of mstsc.exe is reported as “fixed”. For example on my W10Pro-1709 machine that file is 10.0.16299.15 dated 9/29/2017 after completely patching today. In other words it looks like the default Fall Creator’s version and not anything new this month. The Microsoft advisory mentions replacing it but gives no specific guidance or version information in order to verify.

      Anyone have any guidance or insight?

      Thanks!
      -Mike

    • #175658 Reply

      Mr. Natural
      AskWoody Lounger

      According to the Microsoft cve posting it does appear the group policy options are added when installing the update. So I thought I’d install it on my desktop at work to verify. As mentioned I’m running W10 1709 x64 16299.192. According to the cve article my pc should be eligible for KB4088776. So I approve that update in WSUS for the test environment and add my pc to the test group. After it finished downloaded I ran windows update and said “Windows is up to date”…..? I then look to see which Windows 10 systems are eligible for this update and oddly (what has become normal) is that only a handful of W10 systems are showing they need the patch. All of our W10 pc’s are either 1703 or 1709 and only a small number of either version are showing they need the patch. Honestly ever since I’ve worked with Windows 10 machines in a domain environment there’s always been some issues with Windows 10 pro working properly with WSUS. My pc is the only one with any of the March updates. All other systems are up to date with the February updates and no March updates.

      • This reply was modified 7 months, 1 week ago by  Mr. Natural. Reason: inserted html code for some reason
      • This reply was modified 7 months, 1 week ago by  Kirsty.
      • This reply was modified 7 months, 1 week ago by  Kirsty.
    • #175669 Reply

      OscarCP
      AskWoody Lounger

      I have a question:

      For some collaborative research work, I sometimes ftp, or log in remotely, from my Windows 7, Pro, x64 computer, to LINUX and Mac Os machines elsewhere using secure shell (ssh) and secure ftp (sftp) applications for Windows.

      Does anybody know if such applications are likely to use the Windows remote access protocol discussed here? Or if they are they completely separate things, so I should not expect problems, in the near future, with certification?

      Thanks.

       

       

      Thanks.

    • #175810 Reply

      Paul T
      AskWoody MVP

      Secure Shell and Secure FTP do not use Windows remote access, so you are OK.

      cheers, Paul

      1 user thanked author for this post.
    • #176532 Reply

      mcbsys
      AskWoody Lounger

      I just learned that these instructions can cause you to lose RDP access to your servers if you proceed as follows:

      1. Update a Windows 10 1709 client with the March quality update KB4088776.

      2. Deploy the group policy to an unpatched server as described above. Since the server is unpatched, you’ll have to jump through some hoops to get the .admx and .adml files onto the server. Set Encryption Oracle Remediation to Mitigated.

      3. Apply the new group policy to the Windows 10 client.

      4. Try to RDP to the server. You’ll get a popup “An authentication error has occurred. The function requested is not supported.”

      You are now trying to connect a patched, Mitigated client to an unpatched server. As outlined in the matrix at the bottom of KB4093492, this interaction is Blocked.

      Log on to the server directly or from an unpatched machine, change the group policy to Vulnerable, apply the policy, and you will be able to RDP from the patched client.

      Lesson learned:  Do not set Encryption Oracle Remediation to Mitigated on patched clients that need to connect to unpatched servers or you will lose the ability to RDP. Set the value to Vulnerable until the server is patched.

      Blog article updated.

      2 users thanked author for this post.
    • #191252 Reply

      anonymous

      Is there anyone who can post the actual registry setting(s) which should be applied to  RDP clients and servers, for those who prefer this method rather than Group Policy?  Thanks!

    • #191265 Reply

      columbia2011
      AskWoody Lounger

      https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

      Above article describes you how to make registry settings for clients and servers.

      1 user thanked author for this post.

    Please follow the -Lounge Rules- no personal attacks, no swearing, and politics/religion are relegated to the Rants forum.

    Reply To: Patch Lady: Tracking some post release issues

    You can use BBCodes to format your content.
    Your account can't use Advanced BBCodes, they will be stripped before saving.

    Your information: