Using Managed Identity inside of a Remote (PS) Session

[brwilkinson]

I was thinking about the security implications of using Managed Identities inside of PowerShell remoting sessions.

E.g.

# example 1.

Invoke-Command -ComputerName server123 -ScriptBlock {

    Login-AzAccount -Identity -AccountId $using:ClientId
    Get-AzKeyVault | Get-AzKeyVaultSecret | ForEach-Object {
        Get-AzKeyVaultSecret -VaultName $_.VaultName -Name $_.Name
    }
}

# example 2.

Invoke-Command -ComputerName server123 -ScriptBlock {

    Login-AzAccount -Identity -AccountId $using:ClientId
    Get-AzAccessToken
}

I obviously need either RBAC or Keyvault Policy to allow the listing of the Secrets and also Get secrets Etc., however I feel like just allowing and Identity to be used inside of a Remote session doesn't seem like the best default setting.

Managed Identity is supposed to be a Device/Hardware lock and this allows a single machine on the network to be used to grab a Token, then used on any other machine. like a proxy device.

Above is Powershell example, however obviously just using Invoke-RestMethod or Invoke-WebRequest can also work, however I figured I would begin a discussion here.

[dcaro]

@brwilkinson thanks for the comment and happy to discuss this further with you.
In your scenario you would need to have assigned an identity to the VM and assign the proper permissions to this identity to be able to access secrets etc. however, the concern that you expressing is valid beyond the context of managed identity.

Solutions like continuous access evaluation help preventing getting tokens from one environment and using them somewhere else.

[brwilkinson]

@dcaro

It's mostly about the ability to access the Azure Metadata service from Remote Machines.

I could be sitting on a laptop across my Corporate VPN, via Express Route and simply do an invoke command onto a Virtual Machine in Azure (perhaps a hybrid node via Arc) and act on behalf of the Managed Identity.

I know this is not specifically related to the AZ Cmdlets, however I just wanted to be sure people are comfortable with these scenarios.

It seems like a good attack vector. . . with limited controls. . . and now you are relying on Corporate Controls in a Active Directory Domain Environment with Kerberos Authentication as an entry point to connect where any Local Administrator gets access.

Even if a Managed Identity had 'Get' secrets, this seems like a good way to leak them. You may need the RGName, KVName and Secretname, however perhaps if you have Get/List you only need the first two and perhaps a large amount of Admins can get access to that information. . . Even if they don't have GET access permissions on the keyvault as an individual.

Although this is general conversation, not just about any particular resource type, since you could just as easily be getting data from a storage account Etc.

I was wondering if you could detect that the AZ cmdlets were being executed in a Remote session and block access to the metadata service to get the access token? This would be a breaking change.

Like I mentioned this may not be the best place to fix this issue, I mean within the AZ Module, because you can simply use invoke-webrequest/curl to achieve the same thing, however I think it's a conversation that is worth having, even if it's just to document the controls on how to lock this down.

The issue is that unless this was handled by the metadata service to block the requests, then it must fall back to either the AZ Module OR PowerShell remoting security. The problem here is that most organizations don't have good controls here at a corporate level over PowerShell remoting over thousands of nodes. Applocker, whitelisting or JEA, may be what are required; however, I wouldn't put any money that most corporations implement these controls well.

[brwilkinson]

I would prefer if the Azure meta data service could be locked down.

• Similar as to how the windows update API is locked down to local only, the API is not accessible remotely.

Managed Identity is great. I just don’t believe making the meta data service accessible across the network is desirable.

In Enterprise, too many people are given Local Admin access and therefore inherit Access to Azure Resources… where there is no correlation between those roles.

1. Why do you need managed Identity?

   • Access Azure services used for Automation or via Application code locked to only execute on known hardware

2. Does it need to have remote access to fulfill the need above?

   • No

3. Does remote access open up opportunity for exfiltration of data and undesired access?

   • Yes

4. Does it bypass the requirement for Certs/secrets/MFA/Conditional Access?

   • Yes

Mainly trying to avoid these types of scenarios.

# find every computer on the domain.
$CN = get-adcomputer -Filter * | foreach dnshostname
 
# go looking for secrets across the network
Invoke-Command -ComputerName $CN -ScriptBlock {
 
    Login-AzAccount -Identity -AccountId $using:ClientId
    Get-AzKeyVault | Get-AzKeyVaultSecret | ForEach-Object {
        Get-AzKeyVaultSecret -VaultName $_.VaultName -Name $_.Name
    }
}

[dingmeng-xue]

Thanks @brwilkinson , it's good point. Normally, we recommend user to set different permissions per machine. I don't figure out a good way off the top of my head. As you mentioned, user also can send raw HTTP request from that machine.

[brwilkinson]

@dingmeng-xue

Yes it's an interesting one. Ideally it would be blocked at the meta data service level, however since it uses a local address, I am not even sure if that is possible.

Then the question remains, should you block it with the AZ Modules, if you can just use invoke-webrequest (IWR) / Invoke-RestMethod (IRM) or Curl to get access anyway?!

I think that if you do detect the user is in a nested (WSMAN/CIM) session, you can block it for the AZ Modules... then at least you lower the attack area from these tools, which I still think is the right thing to do. Force an attacker to use Curl/IWR, rather than these Cmdlets. That way if this is a breaking change for anyone, they can just go native.

Using DSC is a common way in which you would have to access the metadata service and use the managed identity, however that is invoked locally, so hopefully that would not be blocked.

It might be interesting to get some details of known vulnerabilites via meta data service, I believe AWS had one a while back.

[dingmeng-xue]

Sure. Let's keep discussion for a while. No idea if it's common concern. It also introduce feature breaking change if we block it for Az modules.

[brwilkinson]

Hi @PaulHigin would you mind commenting on the feasibility in detecting if a Cmdlet e.g. 'Login-AzAccount' was running in a remote PowerShell session?

• We were looking to have different functionality depending if it was local session or remote session.

Would you be able to recommend a reliable way to perform the check?

• Also are there known bypasses?
• Or if you can think of any other places this is currently used?

E.g. something like these:

• $host.Name [System.Management.Automation.Internal.Host.InternalHost]
• $pssenderinfo [System.Management.Automation.Remoting.PSSenderInfo]

[dcaro]

Thank you all for this discussion.

Summary:

If a managed identity is granted to an Azure Virtual Machine, a local administrator may be able to inherit from the permissions granted to this identity and gain access to Azure resources.

Conclusions:

• In the case a managed identity is granted to an Azure VM, only local administrator may be able to inherit from the permissions of this identity to access Azure resources from within the VM.

Important: By default, Azure VM do not have a managed identity. By default, local administrators of Azure VMs do not have access to Azure resources.

• Customers are strongly advised to always use least privilege access principle.

  • Remote access to Azure VM for local admin should be limited as much as possible.
  • Permissions granted to managed identities for VM should be as restrictive as possible (for example, avoid “Storage Account Contributor” and use “Storage Blob Data Contributor” to avoid accessing storage account keys).

• Customers should ensure logging is in place to be able to detect as early as possible any suspicious activities.

• Options to prevent this scenario are under considerations but are beyond the sole scope of Azure PowerShell.

We are locking this conversation for now and hope the above recommendations can help our customers be more secure.