Posted on Leave a comment

How to implement Managed Identity on Service Fabric

Workloads deployed in Service Fabric clusters require Azure AD application credentials or managed identities to access Azure AD protected resources, such as Azure Key Vault and storage accounts. In case of Azure AD applications one can create a new app registration then assign permissions from Access control and finally use the client secret of this application inside the service fabric service.

If you need to enhance security and built based on well architected framework principles you can integrate managed identity authentication inside service fabric applications. Typically when you need to deploy an application on service fabric you should connect to the cluster and deploy using powershell commands. If you want to use managed identity it’s a whole different procedure and the first thing that needs to be changed is the deployment of the service inside the sf cluster.

The high level diagram can be found below.

It is mandatory to deploy the service fabric application as an arm template in order to enable managed identity. There is no other way to implement managed identity authentication except from arm templates.

In more detail there are some steps that need to be performed for the deployment:

  • some references for the user assigned managed identity should be added inside service fabric application in ServiceManifest.xml and ApplicationManifest.xml
  • the output package after the build should be bundled in a sfpkg zip format
  • the package should be uploaded in a storage account and it should be accessible from service fabric cluster (sas token)
  • an arm template should be created with some necessary information for the deployment such as application type and version, packageUrl, cluster name, managed identity name etc.
  • arm template should be applied in service fabric cluster resource group

Service fabric cluster configuration

ManagedIdentityTokenService should be enabled on Service Fabric cluster.

https://learn.microsoft.com/en-us/azure/service-fabric/configure-existing-cluster-enable-managed-identity-token-service

Azure configuration

  • Given that you have already created a user assigned Managed Identity you will need to add some references inside the service fabric application.

ApplicationManifest.xml

 <Principals>
    <ManagedIdentities>
      <ManagedIdentity Name="userassignedMI" />
    </ManagedIdentities>
  </Principals>
    <Policies>
      <IdentityBindingPolicy ServiceIdentityRef="SFServiceUser" ApplicationIdentityRef="userassignedMI" />
    </Policies>

ServiceManifest.xml

<ManagedIdentities DefaultIdentity="SFServiceUser">
    <ManagedIdentity Name="SFServiceUser" />
</ManagedIdentities>

https://learn.microsoft.com/en-us/azure/service-fabric/how-to-deploy-service-fabric-application-user-assigned-managed-identity

  • Then the appropriate RBAC should be assigned on the user assigned managed identity which is referenced inside service fabric application.

Code

In our code we can authenticate using Managed Identity instead of a connection string (DefaultAzureCredential class will automatically locate the managed identity configuration and use it).

var blobServiceClient = new BlobServiceClient( new Uri("https://storage.blob.core.windows.net"), new DefaultAzureCredential());

Deployment

The final step would be to deploy the application. Apply arm-template.json to create the SF service.

 az deployment group create --name sfdeployment --resource-group rgofsfcluster --template-file servicefabric-arm.json

Finally application will be created on service fabric cluster using arm templates supporting managed identity authentication.

Posted on Leave a comment

Error from server (Forbidden): nodes is forbidden: User “” cannot list resource “nodes” in API group “” at the cluster scope

kubelogin is a client-go credential (exec) plugin implementing azure authentication. This plugin provides features that are not available in kubectl. It is supported on kubectl v1.11+ and you can bypass interactive authentication with it. This means that you do not have to enter a device code login when interacting with AKS.

I had to use the tool for managed identity authentication with Kubernetes service. In the documentation you can find instructions on how to use it for cases like user login, service principal, managed identity.

https://azure.github.io/kubelogin/concepts/login-modes/msi.html

Although I was following the correct instructions I was struggling with the error shown below when I was executing kubectl commands.

This error was due to the fact that I was not requesting the admin credentials on the kubectl command.

When I was asking for credentials with the below command I ended up with the error.

az aks get-credentials--resource-group rg --name clustername

As I had assigned the Kubernetes admin Cluster role on my managed identity I was able to execute kubectl commands when using.

az aks get-credentials --admin --resource-group rg --name clustername
Posted on Leave a comment

Scan azure devops repositories for credentials and passwords

DevSecOps practices are important for organizations especially when it comes to code repositories. Your code should avoid hard coded passwords and secrets for many reasons as a leak may occur. In this guide I will examine how you can massively scan Azure DevOps repositories for security leaks as passwords and secrets with gitleaks utility.

https://github.com/gitleaks/gitleaks

Simon has provided a very useful script that you can use in order to download all your repositories from Azure DevOps.

Cloning all repositories from Azure DevOps using Azure CLI – Simon Wahlin

When you execute the script, all the repositories will be downloaded inside your project folder.

Then you will need to install gitleaks and execute for each repository.

$folder_for_cleanup = "C:\Users\geralexgr\Documents\AzureRepos"
Get-ChildItem $folder_for_cleanup | Sort -Property FullName | ForEach-Object {
                gitleaks detect -s $_.FullName -v >> gitleaks-results.txt
                echo "######################################################################################################" >> gitleaks-results.txt
            }

The scan will go through each repository and scan for leaks. The output will be stored in gitleaks-result text file.

Posted on Leave a comment

Email spoofing using Postfix – How I hacked my own email for testing purposes

It was a nice morning when I woke up and started surfing before going to work. Little did I know for what will happen that day. Outlook sent me a notification email, the one you can see below. At first I got shocked. I understood immediately that it was a spam email asking for money through crypto payments, but how did the sent it from my email address? The sender was me and the recipient was also me.

If you check carefully the email originator is the same email as the recipient. Did I got hacked? I instantly went to change my passwords and enable MFA option (yes you should do that before you get p0wned).

After contacting my host provider for logs (I wanted to make sure that the mail server was not affected) I started investigating the email. At first it seems like a normal one. By investigating further, I checked the headers.

Oups something seems strange here. The received from headers point an unknown host, the one that tried to trick me. Mister I could send you back the same email from your own address.

Return-Path: <support@brightdirectories.com>
X-Original-To: webmaster@geralexgr.com
Delivered-To: webmaster@geralexgr.com
Received: from cloudvpsserver.host.brightdirectories.com (unknown [64.91.244.139])

spf=pass (sender IP is 64.91.244.139) smtp.mailfrom=support@brightdirectories.com smtp.helo=cloudvpsserver.host.brightdirectories.com

This method of attack is called spoofing and you can read more details from the below article.

https://www.proofpoint.com/us/threat-reference/email-spoofing

Lets try to implement the same attack now, to understand how difficult this could be. The only thing that you will need is a linux machine running postfix and sendmail package. As simple as that and you become a spoofing hacker.

First things first, install and start postfix service.

yum install postfix sendmail; systemctl start postfix

Edit postfix configuration to allow all inet_interfaces.

vi /etc/postfix/main.cf

Then we will try the first spoofing attempt.

[root@centos-lab ~]# sendmail -v webmaster@blablabla.com < mail.txt

The attempt failed. What happened though? By checking the logs, I could find that mail server blocks some incoming messages based on spamhaus service.

Is that hard to bypass? Totally not. You have to go on spamhaus link and whitelist your IP address. The next time the service is updated, your email will be received from the mail server. I have to say that more advanced mail services like google, outlook provide much more sophisticated services to block spam than spamhaus.

By trying to send again my email, I successfully spammed my own mailbox. Lets try a google account this time. I will try to send an email from my personal domain account email to my gmail account. However this would be a spam email as the origin will be a local postfix service that tries to impersonate the real owner.

sendmail -v my_Gmail < mail.txt

You can find my mail.txt contents below.

From: webmaster@blablabla.com
Subject: spoofing email attack this email was sent from an unknown sender using postfix 

Voila. I received a spam email from a sender that is not the original one.

If you check more carefully, google adds a question mark and informs you that it could not verify the owner of the email. However the spam went directly to my mailbox and did not arrive on spam.

If you check the headers again, you will verify that the originator is fake

Original Message
Message ID	<202111202159.1AKLxI8x016745@geralexgr.com>
Created at:	Sat, Nov 20, 2021 at 11:59 PM (Delivered after 2 seconds)
From:	webmaster@blablabla.com
To:	
Subject:	spoofing email attack this email was sent from an unknown sender using postfix
SPF:	FAIL with IP 2.84.53.88 Learn more


Download Original
Copy to clipboard

Delivered-To: 
Received: by 2
Received: from geralexgr.com (IP_address. 
Received-SPF: fail (google.com: domain of root@geralexgr.com does not designate IP as permitted sender) client-ip=xxxxxx;
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of root@geralexgr.com does not designate 2.84.53.88 as permitted sender) smtp.mailfrom=root@geralexgr.com
Received: from geralexgr.com (localhost [127.0.0.1]) by geralexgr.com (Postfix) with ESMTPS id 88E031099F6B for <xxxxxx>; Sat, 20 Nov 2021 23:59:18 +0200 (EET)
Received: (from root@localhost) by geralexgr.com (8.15.2/8.15.2/Submit) Sat, 20 Nov 2021 23:59:18 +0200
Date: Sat, 20 Nov 2021 23:59:18 +0200
Message-Id: <202111202159.1AKLxI8x016745@geralexgr.com>
From: webmaster@geralexgr.com
Subject: spoofing email attack this email was sent from an unknown sender using postfix

As you can see from headers, the real sender is root@localhost and not the sender that is shown on gmail. You can also locate the incoming IP address.

To conclude we examined how one could spoof your email account and impersonate your self. Be very careful on the emails you receive and double check the originator. It is very easy to get hacked with this technique.