[cifs-protocol] [EXTERNAL] Re: MSFT-CVE-2022-21925 MS-BKRP Performing Client-Side Wrapping of Secrets - TrackingID#2207200040005482

Jeff McCashland (He/him) jeffm at microsoft.com
Mon Jul 25 18:59:49 UTC 2022

Hi metze,

Thanks for letting me know, I'm glad it's working better. Please let us know at our DocHelp alias if there's anything we can help with. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Stefan Metzmacher <metze at samba.org> 
Sent: Monday, July 25, 2022 7:56 AM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: [EXTERNAL] Re: MSFT-CVE-2022-21925 MS-BKRP Performing Client-Side Wrapping of Secrets - TrackingID#2207200040005482

Hi Jeff,

> The registry entry to restore the default behavior is:
> [HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-
> 11d1-8c7a-00c04fc297eb]EnableWeakCryptography = 0x1


> Note that the plan is at some point this will go away, as will the ability to restore the default behavior.

Ok, at this point we managed to get it working by removing the BCKUPKEY_PREFERRED (symlink), which means a new public key pair with a new certificate was generated (with a current samba version).
It seems certificates generated by 10 year old samba versions are not accepted.

I may come back to this later, in order to debug the details, but for now it's on hold...


> I have created a DTM workspace for exchanging files related to this issue (credentials and link below). Please find on the workspace 'PartnerTTDRecorder_x86_x64.zip' available for download. These tools can be staged on the Windows client for collecting traces. The instructions below assume they were staged to C:\TDD.
> These traces are highly compressible, please add them to a .zip archive for transferring. To collect the needed traces:
> 1. From a PowerShell prompt, execute:
> C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | 
> Format-Wide -Property 
> ID).formatEntryInfo.formatPropertyField.propertyValue)
> 2. Wait for a little window to pop up in top left corner of your screen, titled "lsass01.run"
> 3. start a network trace using netsh or WireShark, etc.
> 4. Repro the attempted operation
> 5. Stop the network trace and save it
> 6. CAREFULLY: uncheck the checkbox next to "Tracing" in the small "lsass01.run" window. Do not close or exit the small window or you will need to reboot.
> 7. The TTTracer.exe process will generate a trace file, then print out the name and location of the file.
> Compress the *.run file into a .zip archive before uploading with the matching network trace. It is a good idea to reboot the machine at the next opportunity to restart the lsass process.
> Workspace credentials and link:
> Log in as: 2207200040005482_metze at dtmxfer.onmicrosoft.com
> 1-time: M7_h at 91f
> Link: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
> ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz
> I1NiJ9.eyJ3c2lkIjoiZjY5NGMxMTItN2Y4OS00MzNmLWIwYmYtYjhiNjk3ZThmZjlhIiw
> mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI
> 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHA
> iOjE2NjYyOTI0MTksIm5iZiI6MTY1ODUxNjQxOX0.p_X_ajVstNCxah482jUaWEp-gWBwV
> EpjlEsKdU2CwM7M5-fOms77Z34KslF76XVzv8uiSEmUWAC7tMGNjsv7WvPe8aiE_Ufp1OJ
> ZZOjFccnnoiMx4NVP32J1_CD-vSxV6GCzkbo1iF9VMysXd3cUnjgQ6Gk-x41l9HJFZ8AAH
> Fac4aQ5JhXZOgPwr23GwB-H-OYVp91h1UsWQgpYj286biL1_HXktGgudBAJnUr1cpbB150
> BGCOGorEjV4N3eOdWdoVyjhcc25d1UGhR4JwpgF8PplV7VV6wXqznBrnO8-AbA7huIScac
> fkwH3ijxnJoz4RWNlKPwoXBDQtlcuzFPQ%26wid%3Df694c112-7f89-433f-b0bf-b8b6
> 97e8ff9a&data=05%7C01%7Cjeffm%40microsoft.com%7C49d9b50025cc4bbac7
> f508da6e4dc694%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379435775
> 88349619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AKccJBRYSadhYk
> fzY0JGcaiGrBrmC0GaLQlV5sQ5DOg%3D&reserved=0
> Best regards,
> Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft 
> Protocol Open Specifications Team
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: 
> (UTC-08:00) Pacific Time (US and Canada) Local country phone number 
> found here: 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> com%7C49d9b50025cc4bbac7f508da6e4dc694%7C72f988bf86f141af91ab2d7cd011d
> b47%7C1%7C0%7C637943577588349619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> amp;sdata=cxD%2FNuPDcTVg19hLvxmEnVDWyhh10n1xPCiC9HKIOM0%3D&reserve
> d=0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs
> upport.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40micros
> oft.com%7C49d9b50025cc4bbac7f508da6e4dc694%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C637943577588349619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=cxD%2FNuPDcTVg19hLvxmEnVDWyhh10n1xPCiC9HKIOM0%3D&res
> erved=0> | Extension 1138300
> -----Original Message-----
> From: Stefan Metzmacher metze at samba.org<mailto:metze at samba.org>
> Sent: Wednesday, July 20, 2022 5:55 AM
> To: Interoperability Documentation Help 
> dochelp at microsoft.com<mailto:dochelp at microsoft.com>
> Cc: 
> cifs-protocol at lists.samba.org<mailto:cifs-protocol at lists.samba.org>
> Subject: [EXTERNAL] MSFT-CVE-2022-21925 MS-BKRP Performing 
> Client-Side Wrapping of Secrets
> Hi Dochelp,
> I'm currently debugging a problem where client seem to have problems with our MS-BKRP implementation.
> I found the following:
> <18> Section The process of falling back to server-side wrapping using the BACKUPKEY_BACKUP_GUID when retrieval of the server's public key fails using the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID is no longer available by default for the operating systems specified in [MSFT-CVE-2022-21925]. However, the fall back to server-side wrapping can be enabled by adding a registry key designed for this purpose.
> In addition, as noted earlier, Windows clients always retry failing operations once. The resulting process is as follows: The client first tries the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID operation, and if it fails, the client performs DC (2) rediscovery and retries the same operation. If the retry fails, the client tries a BACKUPKEY_BACKUP_GUID operation. If this fails, the client performs DC rediscovery again and retries the BACKUPKEY_BACKUP_GUID operation. If this also fails, an error is returned to the caller.
> I have two questions:
> 1. what is the name and value is for the registry key in order to allow the fallback to server-side wrapping to be activated again.
> 2. Is your tracing tool also able to debug client side powershell 
> scripts? My customer is able to trigger the problem with 
> ConvertFrom-SecureString/ConvertTo-SecureString
> Thanks!
> metze

More information about the cifs-protocol mailing list