§ in Password

[WhiteTomX]

HeyHo, I found a very strange bug today and wondering if it's due to some weird thing about Cyberarks interpretation of JSON or Powershells. But i think it's the first.

I'm not sure if there are other characters that are so weird. I'm quite happy to help once i got some time at work ;=).

Your Environment

• PowerShell Version: 5.1.14409.1018
• psPAS Branch & Version: 3.4.100 from Gallery
• CyberArk Version: Version 10.5.0 (10.5.0.48)

Expected Behaviour

The Account Should be Updated/Created.

Current Behaviour

A not very helpful message is thrown.

Possible Solution

Replacing § with \u00A7 in Invoke-PASCPMOperation.ps1 resolved the issue and the character got saved in Cyberark correctly. I just changed

$ThisRequest["Body"] = $boundParameters | ConvertTo-Json

to

$ThisRequest["Body"] = ($boundParameters | ConvertTo-Json) -replace "§","\u00A7"

I also tried to replace the character before Invoking Invoke-PASCPMOperation but unfortunately \u00A7 got escaped to \\u00A7.

Steps to Reproduce (for bug reports)

$Credential = Get-Credential
$Password = '~%/#`WE33§rA~zAxc`bllYEu^' | ConvertTo-SecureString -AsPlainText -Force

New-PASSession -Credential $Credential -type LDAP -BaseURI $Uri
$CyberarkAccount = Get-PASAccount -search "test@contoso.com"
Invoke-PASCPMOperation -AccountID $CyberarkAccount.ID -ChangeTask -NewCredentials $Password -Debug

Sample Output

New-PASSession -Credential $Credential -type LDAP -BaseURI $Uri
$CyberarkAccount = Get-PASAccount -search "test@contose.com"
Invoke-PASCPMOperation -AccountID $CyberarkAccount.ID -ChangeTask -NewCredentials $Password -Debug
Confirm
Are you sure you want to perform this action?
Performing the operation "Initiate CPM ChangeTask" on target "361_1696".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Yes"): y
DEBUG: [Body] {
    "NewCredentials":  "******",
}
Confirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is "Yes"): y
Invoke-PASRestMethod : [400] There are some invalid parameters: Input parameter for [changeProperties] value is invalid
At line:287 char:4
+             Invoke-PASRestMethod @ThisRequest
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: ({"Details":[{"P...id parameters"}:ErrorRecord) [Invoke-PASRestMethod], Exception
    + FullyQualifiedErrorId : PASWS167E,PASWS168E,Invoke-PASRestMethod

Context

The same error occurs when creating an account.

[WhiteTomX]

HeyHo, to not interfer with the module i made the following workaround in the script I'm writing.

#Copy of Microsofts ConvertTo-Json to prevent § in Password from confusing cyberark. 
#See https://github.com/pspete/psPAS/issues/243
function ConvertTo-Json {
    [CmdletBinding(HelpUri='http://go.microsoft.com/fwlink/?LinkID=217032', RemotingCapability='None')]
    param(
        [Parameter(Mandatory=$true, Position=0, ValueFromPipeline=$true)]
        [AllowNull()]
        [System.Object]
        ${InputObject},

        [ValidateRange(1, 2147483647)]
        [int]
    ${Depth},

        [switch]
        ${Compress})

        (Microsoft.PowerShell.Utility\ConvertTo-Json @PSBoundParameters) -replace "§","\u00A7"
}

Maybe this could be a solution: Using a custom private Function like ConvertTo-PASJson.

[pspete]

Hey @WhiteTomX - interesting report!

I think there are likely other characters which would cause the same behaviour; I replicated the same error with this:

$Password = 'Hello_ª÷æ¾_World!' | ConvertTo-SecureString -AsPlainText -Force

Using your example, I checked the unmasked password value being sent with the request and both the JSON & string are valid/correct:

PS C:\> Invoke-PASCPMOperation -AccountID $CyberarkAccount.ID -ChangeTask -NewCredentials $Password
DEBUG: [Body] {
    "NewCredentials":  "~%/#`WE33§rA~zAxc`bllYEu^"
}

If it is something you want to investigate & work on and you are able to resolve through an update to the module code I would welcome the contribution, but any update to the module should handle more than just the § symbol.

[pspete]

@WhiteTomX - using your workaround, please confirm:

• The password set for the account in the vault contains the unicode character?
  • ~%/#`WE33§rA~zAxc`bllYEu^
• The password value contains the literal escaped unicode string
  • ~%/#`WE33\u00A7rA~zAxc`bllYEu^

[WhiteTomX]

HeyHo, i tried it yesterday and the character was replaced and interpreted by cyberark. Today it wasn't working anymore. I debugged and debugged for some hours. The weird behaviour is, that the proxy-function was invoked, but it diddn't worked. When invoked manually (the -replace "§","\u00A7") it worked. After a break and a chat with my colleague of mine i bumped my head against the wall. The encoding of the file was UTF8. After switching to UTF8-BOM it all worked. I also changed the name of the function (ConvertTo-QJSON) and invoked New-Alias -Name ConvertTo-JSON -Value ConvertTo-QJSON. And in the finally removed the alias, just to be sure not polluting the scope.

But i would not recommend this aproach as it is messy. I try to find some time in the next month to try more characters and maybe get in touch with the support. Then i would like to create a custom function to take care about escaping.

[pspete]

In PSCore, it could be as simple as "§" | ConvertTo-Json -EscapeHandling EscapeNonAscii

Without 100% certainty that these types of characters will not adversely affect operations, I would opt to simply avoid them.

Closing for now as you have your workaround.