Azure Log Analytics – Permission Models

This blog post is all about Log Analytics workspace (later referred as LA) permission models which changed at May 2019. The options (at time of writing) for granting permissions are:

  • Grant access using Azure role-based access control (RBAC).
  • Grant access to the workspace using workspace permissions.
  • Grant access using a specific table in the workspace using Azure RBAC.

These new options gives more granular controls for granting permission to Log Analytics workspaces instead of old model. Anyway, I see still place for granting workspace permissions. It comes back to Log Analytics’ workspace design and organization needs. How operating teams, development teams, and security organization needs to access the performance and security-related events.

There are basically two approaches for Log Analytics design:

  • Centralized
  • Siloed

If you have chosen the centralized model then more granularity access controls might be needed and you can leverage more about new access control modes table (Resource centric RBAC & Table level RBAC).

Access control mode

The new access model is automatically configured to all workspaces created after March 2019.

How to check which access model is in use?

Navigate to Azure Log Analytics and overview page where you can find ”access control mode” options for the workspace.

  • If you are using legacy model ”Access Control mode = require workspace permissions”
  • If new model is in place ”Access Control mode = Use resource or workspace permissions”

With PowerShell

  • If output is true – Log Analytics is using new access model
  • If output is false or null – Log Analytics is using legacy model
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}

How to change access model?

Access model can be changed directory from resource properties and verified from Activity log.

If Powershell is the favorite tool for changes here you go (code from docs.microsoft.com)

$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
    { $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
    { $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force

New Model In Action

The scenario

Siloed Log Analytics workspace design is in use and operational team members needs to maintain Virtual Machines. In practical person needs to read Virtual Machine metrics and performance data from LA.

If new access model is in use members of the team can access the needed logs directly from the resource blade. They cannot see the LA at all because they don’t have global read access to the resource. If user browses to Azure Monitor the user can see logs he/she has access to.

When log search is opened from a resource menu, the search is automatically scoped to that resource and resource-centric queries are used. This means that if users have access to a resource, they’ll be able to access their logs.

Built-in Roles (from docs.microsoft.com)

Azure has two built-in user roles for Log Analytics workspaces:

  • Log Analytics Reader
  • Log Analytics Contributor

Members of the Log Analytics Reader role can:

  • View and search all monitoring data
  • View monitoring settings, including viewing the configuration of Azure diagnostics on all Azure resources.

Nothing prevents from using built-in roles but keep in mind that these are top level permissions. If user has Log Analytics reader permission global read permission with the standard Reader or Contributor roles that include the */read action, it will override the per-table access control and give them access to all log data.

Table Level Access

More granular controls can be achieved with Table level access in case its needed. If centralized Log Analytics model is chosen scenario it might be necessary to grant permissions to different teams to read data from LA tables. This can be achieved with Table level RBAC permissions.

With table level RBAC you can grant permissions only to needed LA tables depending on your needs.

Considerations

If a user has global read permission (Reader or Contributor roles) that include the */read action, it will override the per-table access control and give them access to all log data.

If a user has access to specific LA table but no other permissions, they would be able to access log data through the API but not from the Azure portal.

Summary

Most cases I have worked with, multi-homing Log Analytics design has been used and workspace centric model is enough to satisfy the needs. If centralized model (as few LA’s as possible) would be in use new access model gives more granularity.

Enable Microsoft Security Graph Alerts in Log Analytics

While its not yet configurable in GUI, you can already today configure (with proper prerequisites) the preview for Security Graph API and Log Analytics Integration.

Side note: Similar Integration can be done for Event Hub, and its recommended while enabling LA integration to enable EH integration (if EH exists in tenant)
https://docs.microsoft.com/en-us/graph/security-qradar-siemintegration

While its not yet configurable in GUI, you can already today configure (with proper prerequisites) the preview for Security Graph API and Log Analytics Integration.

Alerts today include  (Check link for original reference)

https://docs.microsoft.com/en-us/graph/api/resources/security-api-overview?view=graph-rest-1.0

I will avoid using the word Azure Monitor here, as this integration is not really in my opinion tapping into any resource API in the Azure Monitor (unless you consider Azure Monitor as umbrella term

AAD Identity Protection Alert
Same alert in Log Analytics
The target in event hub ( I will do separate blog about ELK integration)

integration includes also Event Hub – which has been available for a good while already via similar method

Before proceeding: As always – read the disclaimer in the bottom of the page) I put the disclaimer up also here to emphasize its matter, not just as an escape clause

How To: integration with Log Analytics

  • Disclaimer: The behavior may vary per tenant
  • It took few hours till events started popping up in Log Analytics and event hub
  • To enable the integration You can use existing AAD tokens in cache to achieve this
    • I’ve usually preffered the ADAL libraries to do this bit more simply, but in this case we want to use the AzureRM module to populate parts of the script simply (/done similarly here)


Login-AzureRmAccount
$ctx =Get-AzureRmContext
Get-AzureRmSubscription | Out-GridView -PassThru |Set-AzureRmContext

$rmEndpoint ="https://management.azure.com/providers/Microsoft.SecurityGraph/diagnosticSettings/securityApiAlerts?api-version=2017-04-01-preview"

#Details from IAM API
$Token = Invoke-RestMethod "https://login.windows.net/common/oauth2/token" -Method POST -Body @{
   grant_type="refresh_token"
   refresh_token = ($ctx.TokenCache.ReadItems() | Out-GridView -PassThru ).refreshToken
   content_type = "application/json"
   resource="https://management.core.windows.net/"
}

$json = '
{
  "location": "",
  "properties": {
      "workspaceId": null,
    "name": "securityApiAlerts",
    "serviceBusRuleId": "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.EventHub/namespaces/EVENT_HUB_NAMESPACE/authorizationrules/RootManageSharedAccessKey",
    "logs": [
      {
        "category": "Alert",
        "enabled": true,
        "retentionPolicy": {
          "enabled": true,
          "days": 7
        }
      }
    ]
  }
}
' | ConvertFrom-Json 

$json.properties.serviceBusRuleId = ( (Get-AzureRmResource | where {$_.ResourceType -match "Eventhub"}| Out-GridView -PassThru).resourceID  + "/authorizationrules/RootManageSharedAccessKey")

$json.properties.workspaceId = ((Get-AzureRmOperationalInsightsWorkspace | Out-GridView -PassThru ).resourceID)

$data = Invoke-RestMethod -Uri $rmEndpoint -Method Put -Body ($json | ConvertTo-Json -Depth 4) -UseBasicParsing -Headers @{
Authorization = ($Token.token_type) +" "+ ($Token.access_token)
} -ContentType "application/json; charset=utf-8"



Comment from @samilamppu

its quite likely, that you need to have Security Center Standard with proper event coverage enabled, to get the Node for security alerts under LA

Br,

Joosua

Best tip ever for Azure Security – Security Center built-in policies

As far as the inception of the ASC (Azure Security Center) Security Policies, I’ve been recommending attaching security policies to subscription, or management group.

Best part of this, is that the deployment is handled for you by ASC, if you’ve allowed/configured ASC policies in first place

  • On as side note, once you get comfy with policies, you’ll want to add region restrictions + bunch of best practice policies, but that shall be part of another blog post.

ASC’s default policy initiative

ref: https://docs.microsoft.com/en-us/azure/security-center/security-center-azure-policy 

With the ASC’s default policy initiative you get to audit and monitor the following controls proactively

  • Compute And Apps (14 out of 14 policies enabled)
  • Data (12 out of 12 policies enabled)
  • Identity (10 out of 10 policies enabled)

Kuvaesitys vaatii JavaScriptin.

 

How to assign ASC’s default policy initiative?

If for some reason this isn’t setup for you, you might want to check the following setting in security center

  • Once you’ve acknowledged and understand how you’re inheritance and ASC Plan is configured, you can enable the policies by one simple control ’ Assign Security Policy ’

ASC

3


Once the policies start, you’ll begin see the results of evaluation

  • 289 resources evaluated 🙂 – How great is this!

ASC45

Highly recommended!

Br, Joosua

 

Demonstration – Illicit consent grant attack in Azure AD / Office 365

Disclaimer: All information contained within this post is common knowledge, given you grasp basic concepts of AAD default behavior,  OAuth2 Authorizations and how Javascript works in browsers.


 

How does it work?

Attacker creates multi-tenant app, and adds non-admin requiring API permissions for the desired API’s.  Attacker then delivers the link to end user, which after clicking the link only has to consent (Approve) the API permissions for the attacker.

Attacker has then access to user mail, this happens because attacker exfiltrates in the background the Access Token and uses it against the Exchange Online API

Down below I describe why it might be hard for the user to discern good app from the bad app.

Why it works?

Multi-tenants app by default have access to end users data, unless your Azure AD Admin have disabled the particular defaults that enable this behavior.

 

Exfil.jpg

Graph API + Other API’s

PoC

  • Create multi-tenant Azure AD Web-App/API + Azure Web App that delivers the JS. client side code to browser from Node.JS Web App
  • I am using minified ADAL.JS as <script src in the code. Other than that, I’ve just added few custom functions to the code, and studied wide variety of existing Vanilla ADAL JS Apps in GitHub
  • Figure out a way to deliver the link to the victim/victims in other AAD / Office 365 tenants
  • I’ve opted to forge existing Microsoft Newsletter with link to malicious Azure Web App to
  • When user clicks the link consent dialog is prompted.

JSA.PNG

  • Consent – This as any other dialog, you would get prompted for when consent framework kicks in (This is where the confidence part happens)

Newsletter.PNG

The process is same for benign apps, so there is superficially nothing to separate the good app from the bad (except caution, which is often unheeded, if you consider how often an mobile application presenting similar dialog is approved for multiple permissions in mobile phone)

  • User is redirected to the malicious app with seemingly benign OIDC-Flow (response_type=id_token)… no mention here of the OAuth2 Implicit Grant Flow (yet)

Redir

  • Hidden iFrame executes the OAuth2 Implicit Grant Flow, and gains Access Token to resource

Tokens

  • AJAX HTTP is used to post the Access Token as Payload to external exfil service
    • In case you wonder, that I’d left the function key there :)… Just try

JAX

  • User is redirected to the original link requested in the mail

OH.PNG

<- Users timeline stops here


 

– >Perpetrators timeline begins here

  • Token is copied by the malicious actor from Azure Functions where it was posted

Exfil

JWTIO

  • A Separate Powershell session running in some dark corner of the world is now searching users mail content for several keywords, and playing with the Access Token for the next 3600 seconds

Passwords

 

See it live:

Evil side:

User side

 

 

 

Microsoft References

https://docs.microsoft.com/en-us/office365/securitycompliance/detect-and-remediate-illicit-consent-grants 

https://blogs.technet.microsoft.com/office365security/defending-against-illicit-consent-grants/

Microsoft has issued multiple items in Secure Score controls about the scenario

Stay tuned for PT2 (How to defend against it)