[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] [EXTERNAL] Re: MSFT-CVE-2022-21925 MS-BKRP 3.2.4.1 Performing Client-Side Wrappi
From: "Jeff McCashland \(He/him\) via cifs-protocol" <cifs-protocol () lists ! samba ! org>
Date: 2022-07-25 18:59:49
Message-ID: BN6PR21MB0628FF71863BD4D44BE5907DA3959 () BN6PR21MB0628 ! namprd21 ! prod ! outlook ! com
[Download RAW message or body]
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@samba.org>
Sent: Monday, July 25, 2022 7:56 AM
To: Jeff McCashland (He/him) <jeffm@microsoft.com>
Cc: cifs-protocol@lists.samba.org; Microsoft Support <supportmail@microsoft.com>
Subject: [EXTERNAL] Re: MSFT-CVE-2022-21925 MS-BKRP 3.2.4.1 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
Thanks!
> 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...
Thanks!
metze
> 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@dtmxfer.onmicrosoft.com
> 1-time: M7_h@91f
>
> Link:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
> ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz
> I1NiJ9.eyJ3c2lkIjoiZjY5NGMxMTItN2Y4OS00MzNmLWIwYmYtYjhiNjk3ZThmZjlhIiw
> ic3IiOiIyMjA3MjAwMDQwMDA1NDgyIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtY
> mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI
> 4ZjhmOTk0NS01ZDE4LTRkYWQtOThhMS01ZWY3MjI0ODU5ZWYiLCJpc3MiOiJodHRwczovL
> 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@samba.org<mailto:metze@samba.org>
> Sent: Wednesday, July 20, 2022 5:55 AM
> To: Interoperability Documentation Help
> dochelp@microsoft.com<mailto:dochelp@microsoft.com>
> Cc:
> cifs-protocol@lists.samba.org<mailto:cifs-protocol@lists.samba.org>
> Subject: [EXTERNAL] MSFT-CVE-2022-21925 MS-BKRP 3.2.4.1 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 3.2.4.1: 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
>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic