Initial Discovery in Azure Application Insights

Tenable Research initially uncovered the vulnerability within Azure Application Insights, a service designed to monitor and analyze web applications’ performance and availability. The Availability Tests feature of Azure Application Insights, intended to check the accessibility and performance of applications, was found to be susceptible to abuse. Users can control server-side requests in these tests, including adding custom headers and changing HTTP methods. This control can be exploited by attackers to forge requests from trusted services, mimicking a server-side request forgery (SSRF) attack.

Expansion to More Than 10 Other Azure Services

Upon further investigation, Tenable Research found that the vulnerability extends beyond Azure Application Insights to more than 10 other Azure services. These include:

• Azure DevOps
• Azure Machine Learning
• Azure Logic Apps
• Azure Container Registry
• Azure Load Testing
• Azure API Management
• Azure Data Factory
• Azure Action Group
• Azure AI Video Indexer
• Azure Chaos Studio

Each of these services allows users to control server-side requests and has an associated Service Tag, creating potential security risks if not properly mitigated.

How Attackers Can Exploit the Vulnerability

Attackers can exploit the vulnerability in Azure Service Tags by abusing the Availability Tests feature in Azure Application Insights. Below are detailed steps and examples to illustrate how an attacker can exploit this vulnerability:

1. Setting Up the Availability Test:

• Example Scenario: An attacker identifies an internal web service within a victim’s Azure environment that is protected by a firewall rule allowing traffic only from Azure Application Insights.
• Action: The attacker sets up an Availability Test in Azure Application Insights, configuring it to target the internal web service.

2. Customizing the Request:

• Manipulating Headers: The attacker customizes the HTTP request headers to include authorization tokens or other headers that may be expected by the target service.
• Changing HTTP Methods: The attacker can change the HTTP method (e.g., from GET to POST) to perform actions such as submitting data or invoking actions on the target service.
• Example Customization: The attacker configures the test to send a POST request with a custom header “Authorization: Bearer <malicious-token>”.

3. Sending the Malicious Request:

• Firewall Bypass: The crafted request is sent through the Availability Test. Since it originates from a trusted Azure service (Application Insights), it bypasses the firewall rules based on Service Tags.
• Example Attack: The Availability Test sends the POST request with the custom header to the internal web service, which processes the request as if it were from a legitimate source.

4. Accessing Internal Resources:

• Unauthorized Access: The attacker now has access to internal APIs, databases, or other services that were protected by the firewall.
• Exfiltration and Manipulation: The attacker can exfiltrate sensitive data, manipulate internal resources, or use the access to launch further attacks.
• Example Impact: The attacker retrieves confidential data from an internal API or modifies configuration settings in an internal service.

Detailed Example of Exploit

Scenario: An organization uses Azure Application Insights to monitor an internal financial service. The service is protected by a firewall rule that allows access only from the ApplicationInsightsAvailability Service Tag.

1. Deploying an Internal Azure App Service:
   • The organization has a financial application hosted on an Azure App Service with firewall rules configured to accept traffic only from the ApplicationInsightsAvailability Service Tag.
2. Attempted Access by the Attacker:
   • The attacker discovers the endpoint of the internal financial application and attempts to access it directly. The firewall blocks this attempt, returning a forbidden response.
3. Exploiting the Vulnerability:
   • Setting Up the Test: The attacker sets up an Availability Test in Azure Application Insights targeting the internal financial application.
   • Customizing the Request: The attacker customizes the test to send a POST request with a payload that triggers a financial transaction, adding a custom header “Authorization: Bearer <malicious-token>”.
   • Sending the Request: The Availability Test sends the POST request to the internal financial application, bypassing the firewall.
4. Gaining Unauthorized Access:
   • The financial application processes the POST request, believing it to be from a legitimate source. The attacker successfully triggers the financial transaction.
   • Exfiltration: The attacker sets up another Availability Test to send GET requests with custom headers to extract financial records from the application.

Advanced Exploitation Techniques

1. Chain Attacks:

• Attackers can chain multiple vulnerabilities or services together to escalate their privileges and impact. For example, using the initial access gained from the Availability Test to find other internal services or to escalate privileges within the Azure environment.

2. Lateral Movement:

• Once inside the network, attackers can move laterally to compromise other services or extract further data. They might use other Azure services like Azure DevOps or Azure Logic Apps to find additional entry points or sensitive data.

3. Persistent Access:

• Attackers can set up long-term Availability Tests that periodically execute, ensuring continuous access to the internal services. They might use these persistent tests to maintain a foothold within the environment, continuously exfiltrating data or executing malicious activities.

Defensive Measures

To mitigate the risks associated with this vulnerability, Azure customers should implement several defensive measures:

1. Analyze and Update Network Rules:

• Conduct a thorough review of network security rules.
• Identify and analyze any use of Service Tags in firewall rules.
• Assume services protected only by Service Tags may be vulnerable.

2. Implement Strong Authentication and Authorization:

• Add robust authentication and authorization mechanisms.
• Use Azure Active Directory (Azure AD) for managing access.
• Enforce multi-factor authentication and least privilege principles.

3. Enhance Network Isolation:

• Use network security groups (NSGs) and application security groups (ASGs) for granular isolation.
• Deploy Azure Private Link to keep traffic within the Azure network.

4. Monitor and Audit Network Traffic:

• Enable logging and monitoring of network traffic.
• Use Azure Monitor and Azure Security Center to set up alerts for unusual activities.
• Regularly review logs and audit trails.

5. Regularly Update and Patch Services:

• Keep all Azure services and applications up to date with security patches.
• Monitor security advisories from Microsoft and other sources.
• Apply updates promptly to minimize risk.

6. Use Azure Policy to Enforce Security Configurations:

• Deploy Azure Policy to enforce security best practices.
• Create policies that require strong authentication and proper network configurations.
• Use Azure Policy initiatives for consistent application across resources.

7. Conduct Security Assessments and Penetration Testing:

• Perform regular security assessments and penetration testing.
• Engage with security experts or third-party services for thorough reviews.
• Use tools like Azure Security Benchmark and Azure Defender.

8. Educate and Train Staff:

• Provide training on risks and best practices related to Azure Service Tags and network security.
• Ensure staff understand the importance of multi-layered security.
• Equip teams to implement and manage security measures effectively.

The vulnerability discovered by Tenable Research highlights significant risks associated with relying solely on Azure Service Tags for firewall rules. By understanding the nature of the vulnerability and implementing the recommended defensive measures, Azure customers can better protect their environments and mitigate potential threats. Regular reviews, updates, and a multi-layered security approach are essential to maintaining a secure Azure environment.

The post Your Azure Security at Risk? How Hackers Are Exploiting Azure Service Tags (And How to Stop Them)? appeared first on Information Security Newspaper | Hacking News.

Let’s consider a hypothetical example to understand the implications of CVE-2023-36052:

Suppose a development team uses Azure CLI for managing their Azure resources and automates their deployment process using GitHub Actions. During their routine operations, they execute various Azure CLI commands which generate logs. These logs, by default, include plaintext credentials such as usernames and passwords.

An external attacker, aware of this vulnerability, could access the public repository where the team’s GitHub Actions are configured. By examining the CI/CD logs published there, the attacker could find and extract these plaintext credentials. With these credentials, the attacker could gain unauthorized access to the team’s Azure resources, potentially leading to data breaches, unauthorized modifications, or even service disruptions.

This scenario underscores the critical nature of CVE-2023-36052, where seemingly benign logs could inadvertently become a source of significant security breaches. The mitigation steps provided by Microsoft, including updating Azure CLI and implementing best practices for log management and key rotations, are essential to prevent such unauthorized access.

Mitigation

Microsoft implemented several measures to address this vulnerability. These include:

1. Azure CLI Update: Advising customers to update Azure CLI to the latest release.
2. Securing Logs: Avoiding exposure of Azure CLI output in logs or publicly accessible locations and implementing guidance for masking environment variables.
3. Regularly Rotating Keys and Secrets: Encouraging regular rotation of keys and secrets.
4. Reviewing Security Best Practices: Providing guidance on secrets management for Azure services and GitHub Actions, and ensuring GitHub repositories are private unless necessary to be public.
5. Securing Azure Pipelines: Offering guidance for securing Azure Pipelines.
6. Enhancing Default Configurations: Introducing a new default configuration in Azure CLI to prevent accidental disclosure of sensitive information. This included restricting the presentation of secrets in output from update commands and broadening credential redaction capabilities across GitHub Actions and Azure Pipelines.

Workaround

Without patching, the primary alternative way to mitigate the risks associated with CVE-2023-36052 involves several best practices and security measures:

1. Secure Logging Practices: Ensure that logs do not contain sensitive information. This might involve custom scripts or tools to filter out or obfuscate credentials and other sensitive data before they are logged.
2. Access Control on Logs: Restrict access to CI/CD logs. Ensure that only authorized personnel can view these logs, and they are not publicly accessible.
3. Frequent Credential Rotation: Regularly change credentials and secrets to reduce the window of opportunity for an attacker to use compromised credentials.
4. Monitoring and Alerting: Implement monitoring to detect unusual access patterns or usage of credentials, which might indicate a compromise.
5. Environment Segmentation: Segregate development, testing, and production environments. Limit the scope of what each environment can access to minimize potential damage.

However, these measures are more complex and potentially less effective than updating the Azure CLI to a patched version. Patching directly addresses the vulnerability at its source, providing a more comprehensive and straightforward solution.

The post Azure CLI stores credentials in plaintext in logs. A easy technique to hack cloud environments appeared first on Information Security Newspaper | Hacking News.

In the last chapter we saw on how to add resource to a VNet now in this chapter we will see how we will enable connectivity between two virtual networks. As we know that each virtual network is an isolated environment and for 2 resources in different two virtual network to talk to each other we will have to enable communication between two virtual networks. Azure Virtual network peering is supported within and across regions. We will start by creating two virtual networks, then verify routes between them before enabling peering. After enabling peering we will see what peering does.

1. Start by creating a vnet as explained earlier in chapter 2. We created vnet1 in the below screenshot and review our configuration before be create our first vnet1.

2. After clicking create our first virtual network with name as vnet1 with subnet1 (192.168.1.0/24) will be created in East US.
3. Now we will create another virtual network vnet2 and review configuration before clicking create

4. After clicking create our second virtual network with name as vnet2 with subnet2 (192.168.2.0/24) will be created in East US 2.
5. Now we will add resource to each subnet and we will add one virtual machine to each subnet
6. We are adding first virtual machine to vnet1_subnet1 once we create it will bring up our first VM

7. We will add second virtual machine to vnet2/subnet2 as shown below:

8. As we can see in the list of virtual machines below that our both virtual machines in different virtual networks across between regions is ready as shown below:
   • Name of VM1: vnet1-subnet1-vm1
     • Public IP: 52.170.1.138, Private IP: 192.168.1.4
   • Name of VM2: vnet2-subnet2-vm2
     • Public IP: 20.14.205.40, Private IP: 192.168.2.4

9. Now lets try ping between both these machines before we enable vnet peering. Both will not ping each other as shown below:
   • Name of VM1: vnet1-subnet1-vm1
     • Public IP: 52.170.1.138, Private IP: 192.168.1.4
   • Name of VM2: vnet2-subnet2-vm2
     • Public IP: 20.14.205.40, Private IP: 192.168.2.4

10. Lets also check the routes between VM’s

11. Now lets enable vnet peering between virtual networks

12. Once you add peering ping will start working between virtual machines in different virtual networks

13. Lets see routes and see what has been modified or added. To see routes go to Virtual machines > vnet1-subnet1-vm1 > Networking > Network Interface >Effective routes. You will see route with next hop as VNetGlobalPeering

14. Topology is as shown below:

The post Azure cloud security tutorial series – Chapter 4 [Establish VNet Peering] appeared first on Information Security Newspaper | Hacking News.

In the last chapter (Azure cloud security tutorial series – Chapter 2 [Virtual Network]) we saw on how to create VNet in Azure. Once you have VNet created its time to add resources to it. It like once you have your virtual network created you will add computers, servers and other types of devices to it, as the network is private to you. In this chapter we will show you on how we can add 2 virtual machines to our VNet/subnets. To recap in last chapter we added one VNet and added 2 subnets to our VNet. Now in this chapter we will add one Virtual machine in each subnet.

Create a virtual machine in the virtual network

In this we will create a virtual machine in subnet1

1. To access the Azure portal, go to http://portal.azure.com
2. Click on All services > Compute > Virtual machine

3. Hover your mouse over it and you will see + sign. Click on + sign and you will land up in below screen:

We will talk about all the options to select:

Subscription – Free Trial

Resource Group – rg_FreeTrial

Virtual Machine Name – vnet1-subnet1-vm1

Region – Us East US

Availability Option – This options help to keep backup of your resource in case of any failure. 

Security Type – Its like how you want your virtual machine to be accessed. You want to have a simple lock or a stronger lock for additional security.

Image – Choose the Base image of the operating system. In the other words it’s the operating system you want to have in your Virtual machine. 

VM Architecture – It talks about the CPU architecture of virtual machine

Run with Azure spot discount – Its like getting deal on your hotel booking being that you are flexible on your timing. If you choose this option in Azure while creating Virtual machine, you are saying that you are fine to grab discount on cost by using it when its available. There can be chances if someone is willing to pay more for it, you might can lose it.

Size – There are many different type of Virtual machine sizes Azure provides. Azure does this by providing VM series as explained below:

A-Series: These are basic virtual machines, which are suitable for basic working, you can use them for webservers and small databases.

B-Series: B stands for Budget. These Virtual machines are good for work where you need variable performance. They can not take too much load but you get good performance temporarily when required but return to lower performance when not in use.

D-Series: These types are Virtual machines are used when you require high CPU and memory. They are good for remote working and hosting application, large databases.

E-Series: Virtual machines are more designed for providing memory and computational power. They are suitable for memory intensive applications, data warehousing and real time analytics.

F-Series: Virtual machines that require high CPU commonly used for gaming servers, scientific modeling.

G-Series: Virtual machines designed for lot of memory and computational power, they are ideal for SQL server workloads.

H-Series: Used for complex scientific computation. They provide powerful CPU and GPU.

L-Series: VM that require large amount of local storage like big data applications.

M-Series: VM that require lot of memory and fast storage suck as relational databases and big data workloads.

N-Series: VM that require GPU enabled and are used for graphic intensive workloads like gaming and AI/Machine learning.

Administrator account – Mention the way you want to connect to Virtual machine wither through password less way (.i.e. is with SSH key) or using password

Inbound port rules – Keep it to None. We talks about which ports are allowed from outside world or public internet. None means everything is blocked from outside or public internet.

4. Click Next : Disks, you will get following options

When you create Azure VMs it provides one operating system disk and a temporary disk for short-term storage. You can attach additional data disks. The size of the VM determines the type of storage you can use and the number of data disks allowed.

This page talks about configuration of these 2 types of Azure managed disks, one operating system disk and a data disk if configured.

VM disk encryption – It is used to encrypt your data stored in Azure managed disks (OS and data disks). As said Azure disk storage encryption automatically encrypts your data stored on Azure managed disks (OS and data disks) at rest by default when persisting it to the cloud.

OS (Operating system) Disk type – Azure provides following types of disks that go with your Virtual machine for storing operating system. The following table provides a comparison of the five disk types to help you decide which to use. Refer https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types 

Key management – Suppose you a storing very confidential data on the Azure managed disks you can use Azure provided key or generate your own keys for encryption and decryption.  

5. Click Next, to move to Networking section

Virtual Network – Select vnet1. Definition as stated by Azure: 

Virtual networks are logically isolated from each other in Azure. You can configure their IP address ranges, subnets, route tables, gateways, and security settings, much like a traditional network in your data center. Virtual machines in the same virtual network can access each other by default.

Subnet – Select vnet1-subnet1. Definition as stated by Azure:

A subnet is a range of IP addresses in your virtual network, which can be used to isolate virtual machines from each other or from the Internet.

Public IP – Use a public IP address if you want to communicate with the virtual machine from outside the virtual network.

NIC network security group – A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, the virtual machine. To simplify management of security rules, it’s recommended that you associate a network security group to individual subnets, rather than individual network interfaces within the subnet, whenever possible.

Public inbound ports – None

By default, access to the virtual machine is restricted to sources in the same virtual network, and traffic from Azure load balancing solutions. Select None to confirm, or choose to allow traffic from the public internet to one of these common ports.

Delete public IP and NIC when VM is deleted – check it

Public IP addresses and NICs persist independently from the virtual machine. You can choose to automatically delete the public IP address and NIC when the associated virtual machine is deleted

Load balancing – We don’t have load balancer, leave it default

6. Click Next to move to management Tab

Enable system assigned managed identity – 

A system assigned managed identity enables Azure resources to authenticate to cloud services (e.g. Azure Key Vault) without storing credentials in code. Once enabled, all necessary permissions can be granted via Azure role-based access control. The life cycle of this type of managed identity is tied to the life cycle of this resource. Additionally, each resource (e.g. Virtual Machine) can only have one system assigned managed identity.

Login with Azure AD –

Use your corporate Active Directory credentials to log in to the VM, enforce MFA, and enable access via RBAC roles.

Keep other setting default

7. Click on Advance it provides options to run script on VM start.

8. Choose Tags default and go to Review+create it will land on below page to create VM

9. Once VM created you will get below screen:

Create another virtual machine in the virtual network 

1. Now we create another virtual machine in subnet2, will follow same steps above. After all Virtual machine 2 configuration we will get final screen for review:

2. Now create VM2 and you will get:

3. When you got virtual machines you will see below output:

4. If you go to any virtual machine > vnet1-subnet1-vm1 | Networking > on right hand side you will see topology. 
5. Once you click on it you can also download your topology from Azure.

6. Click on it you will get final topology:

Allow SSH to Virtual machines in Azure 

1. Add inbound rule in VM > Networking as shown below. Click on Add inbound rule and allow SSH from anywhere.
2. Rule highlighted in yellow in added one.

3. Now you can SSH from internet.

The post Azure cloud security tutorial series – Chapter 3 [Add resource to VNet] appeared first on Information Security Newspaper | Hacking News.

Network is combination of many different systems connected together. In the Azure cloud security tutorial series – Chapter 1 [Azure Account] we talked about virtual network is a private space in a network where you can play around within systems in that virtual network. It’s a more secure way of putting your own network within a network. Virtual network is also called VNet in the Azure cloud or Microsoft cloud.

Create Virtual Network Step by Step

1. To create virtual network step by step we will login into https://portal.azure.com and then go to All services > Networking > Virtual Networks

2.  Hover your mouse over it and you will see + sign. Click + sign

3. Once you click on Create Virtual network you will see below screen:

Subscription – Select Free Trial

Resource Group – To understand resource group, image how do you manage files on your computer. You create a folder and them put similar files in that folder. Similarly resource group in Azure helps you to manage and organize similar resources using resource group.

4. Keep Security tab to default values 
5. In IP Addresses add two subnets as shown below.

6. Keep tags to default
7. Now got to Review + create or click Next

8. After creating you will get screen below:

9. Now we will add resources to VNet and subnets in next post.

The post Azure cloud security tutorial series – Chapter 2 [Virtual Network] appeared first on Information Security Newspaper | Hacking News.

Azure is the mostly used cloud in IT organizations. Before cloud came into existence many companies or organizations were using Microsoft products in their organization like Windows OS, MS Office and even Microsoft server OS on their servers for running internal authentication server called AD and others. So it is easy for all organization to move to cloud that too of Microsoft, as the organization IT admins were already having hands on Microsoft products. So after cloud came into existence many organization migrated to cloud of Microsoft called Azure. There are few terms to understand before we move further:

Azure –  It’s a name given to Microsoft cloud.

Azure subscription – As we have a ticket to theme park. Once we have the ticket we can play around with all the rides in that theme park. Just like a ticket Azure subscription is a ticket to get into Azure and play around or we can say utilize different resources available there. These resources can be Virtual machines, Storage, database.  

VNet – Azure cloud is very vast having thousands of Systems, Databases and other devices connected together. VNet provide a logical isolation of Azure cloud dedicated to your Azure subscription.  With VNet you can connect your Azure resources with your on premises network.

Subnets – It’s a subset of Azure VNet. With the help of subnet you can segment your Azure resources within VNet in a smaller address space. 

Address space – To understand what address space is, think of a network where each device is allocated an IP Address between 192.168.1.0 to 192.168.1.255. So for the network 192.168.1.0-192.168.1.255 is the address space. 

Virtual machine – To understand the Virtual machine concepts, think that Microsoft has purchased a big computer and connected that computer on cloud. Now to earn money from this big computer on cloud, Microsoft decided to create small computers from this big computer and will rent these small or you can say virtual computers to the world. The more people will use these virtual computers the more Microsoft will earn. 

Now to understand Azure in a practical manner. We will start by creating a VNet in Azure tutorials and under this VNet we will create 2 subnets. Under each subnet we will add one Virtual machine.

Follow below steps to create account in Azure portal and subscription.

1. Go to https://azure.com

2. Go to Try Azure for Free
3. And then go to start free

4. It will ask to login into microsoftonline.com portal, if you don’t have credentials create new.

5. Once you are logged in you will have to fill in below form:

6. Next it will ask for credit or debit card information. You will be charged when you will migrate from pay as you go service. As we have opted for Free account we will get $200 approx. 13K INR of credit.
7. It will debit Rs. 2 from your card and once payment is confirmed you will be redirected to Go to Azure portal page.

8. Now go to Azure portal button or go to https://portal.azure.com login as email and password you provide to login in microsoftonline.com. Once you are logged in you will land onto Azure dashboard.

The post Azure cloud security tutorial series – Chapter 1 [Azure Account] appeared first on Information Security Newspaper | Hacking News.

Both of the vulnerabilities that Orca found take use of a vulnerability in the postMessage iframe, which makes it possible for Window objects to communicate with one another across domains.The vulnerabilities allowed for illegal access to the victim’s session inside the compromised Azure service iframe. This may result in serious repercussions, such as unauthorized data access, unauthorized alterations, and interruption of the Azure services iframes, among other things. This meant that the vulnerability could be exploited to embed endpoints into remote servers by utilizing the iframe element. This would eventually result in the execution of malicious JavaScript code, which would compromise sensitive data.

However, in order to take advantage of these vulnerabilities, a threat actor would first need to undertake reconnaissance on various Azure services in order to identify vulnerable endpoints contained inside the Azure interface. These endpoints may be missing X-Frame-Options headers or have Content Security Policies (CSPs) that are inadequate.

The attacker will continue to exploit the misconfigured endpoint after they have successfully embedded the iframe in a remote server. They are concentrating on the postMessage handler, which is responsible for handling remote events like postMessages.

The adversary might later construct suitable payloads by embedding the vulnerable iframe in an actor-controlled server (for example, ngrok) and establishing a postMessage handler that delivers the malicious payload if they first analyzed the genuine postMessages sent to the iframe from portal.azure[.]com and then analyzed the postMessages sent from portal.azure[.]com to the iframe.

Because of this, when a victim is tricked into visiting the compromised endpoint, the “malicious postMessage payload is delivered to the embedded iframe, triggering the XSS vulnerability and executing the attacker’s code within the victim’s context.”

During the course of a proof-of-concept (PoC), it was discovered that a postMessage that had been carefully written might be used to alter either the Azure Bastion Topology View SVG exporter or the Azure Container Registry Quick Start in order to carry out an XSS payload.

The post Easily hack into Azure Bastion and Azure Container Registry via XSS vulnerabilities appeared first on Information Security Newspaper | Hacking News.

Recent study conducted by the Ermetic research team uncovered three vulnerabilities in the Azure API Management service. On an internal Azure workload, these included two SSRF vulnerabilities, which stand for server-side request forgery, and a file upload path traversal vulnerability. In the API Management developer interface, the vulnerabilities were triggered by using url formatting bypasses and an unfettered file upload feature. SSRF is a vulnerability that gives an attacker the ability to submit a constructed request from a susceptible server to a selected external or internal server or service. An attacker may exploit this vulnerability to get access to sensitive information. Attackers would be able to submit malicious files to Azure’s hosted internal workload as well as to self-hosted developer portals if the file upload path traversal vulnerability was exploited.

Full SSRF on Azure API Management CORS Proxy

Customers are now able to get a schema from a URL and use it in their API thanks to the addition of the “Import from URL” capability in Azure API Management. This feature was built by Azure. When you have finished specifying the URL of the schema, the Azure API Management CORS Proxy will retrieve the schema by sending an HTTP request to the specified URL in order to retrieve it. Through the process of intercepting, modifying, and adding CORS headers, the CORS Proxy enables communication that is uninterrupted across domains.

Attackers might make requests between the service’s CORS Proxy and the hosting proxy itself by utilizing the SSRF vulnerabilities. This would allow the attackers to access internal Azure assets, refuse service, and circumvent web application firewalls.

They were able to access Azure internal services by using this to overcome the redirection in the following ports:

30001 – Authenticated view of the developer portal 

30004 – Azure’s Management API

30005 – Azure’s Kudu API management

30006 – Unpublished developer site (Unauth)

After entering the Ocp-Apim-Url that pointed to their redirect server, they received a visit from the CORS Proxy, which successfully followed their redirect to the following location: http://localhost:30005/test.

Full SSRF on the Azure API Management Hosting Proxy

Users have the ability to specify the frontend, backend, inbound, and outbound processing of the API while they are configuring the service. When configuring an API’s backend service URL in a dynamic manner, the “set-backend-service” policy is what you’ll need to use. The “base-url” parameter’s value is used to determine what the backend URL will be set to when the policy is applied.During the investigation of the functionality, they discovered that the API Management proxy, located at https://apimanagement.hosting.portal.azure.net/, was used in both the incoming and the outgoing processing to establish the rules. A request that is made from the frontend that the user specifies will first be sent to the inbound processing proxy, and then it will be forwarded to the backend that the user has defined.

Abusing the set-backend-service policy and directing it to the desired site for an SSRF exploit, such as http://localhost, is one way that SSRF might be abused.

Unrestricted File Upload Path Traversal in the API Management Developer Portal

Additionally, they investigated the Azure developer portal for the API Management service, and during investigation, they found that the server supported unrestricted file uploads. The authorized mode of the developer portal gives you the ability to submit static files and graphics that may be displayed on your own dedicated portal. In a nutshell, this finding has repercussions not just for Microsoft Azure itself but also for end customers who have independently set up the developer portal. On a portal “publish,” the files are uploaded to a special Azure blob and the developer portal filesystem, both of which are hosted by Azure and are unavailable to Azure users. Through the developer portal, users can access the files under the path that has been specified, as well as under /content/x.png as the default location.

It has come to notice that Azure does not check either the file type or the location of the uploaded files. Authenticated users are able to traverse the path that is indicated when files are being uploaded, upload malicious files to the developer portal server, and perhaps execute code on it by employing DLL hijacking, iisnode config swapping, or any other appropriate attack vector. Authenticated users may also download files from the server.

Azure’s API Management service was made vulnerable due to these three different vulnerabilities, all of which have now been fixed by MSRC.

The post Easily hack into Azure internal workloads & API using Azure API Management service flaws appeared first on Information Security Newspaper | Hacking News.

“It is feasible to abuse and utilize Microsoft Storage Accounts by manipulating Azure Functions to steal access-tokens of higher privilege identities, move laterally, possibly access important company assets, and execute remote code (RCE),” Orca stated in a recent study that was shared . “This can be accomplished by abusing and using Azure Functions.”

The exploitation route that forms the basis of this attack is a system known as Shared Key authorization. Storage accounts have this mechanism activated by default, so it can be exploited easily.

Microsoft claims that when a storage account is created in Azure, two access keys with a total length of 512 bits are generated automatically. These keys may be put to use to authorize access to data either via the Shared Key authorization protocol or through the use of SAS tokens that have been signed with the shared key.

According to the cloud security company, it is possible to steal these access tokens by manipulating Azure Functions. This might make it possible for a threat actor who has access to an account with the Storage Account Contributor role to escalate privileges and take control of systems.

If a managed identity were to be used to activate the Function app, for example, it might be misused to carry out any command. When you deploy an Azure Function app, a dedicated storage account is automatically generated for the app. This, in turn, makes it feasible to do what we just discussed.

After an adversary has discovered the storage account of a Function app that has been provided with a robust managed identity, they are able to execute code on the app’s behalf and, as a consequence, get an increase in their subscription privileges (PE).

In other words, a threat actor is able to raise their privileges, move laterally, access additional resources, and even run a reverse shell on virtual machines if they exfiltrate the access-token of the managed identity that is allocated to the Azure Function app and send it to a remote server.

To travel laterally, exploit, and compromise the most priceless crown jewels of victims, an attacker may steal and exfiltrate a higher-privileged identity by altering function files in storage accounts, according to Nisimi.

It is advised that companies think about removing Azure Shared Key authorization and instead adopting Azure Active Directory authentication as a mitigating strategy. Microsoft said in a coordinated disclosure that it “plans to enhance how Functions client tools function with storage accounts.” This statement was made in reference to the company’s upcoming changes.

“Among them are modifications to provide improved support for use cases using identities. After the new experiences have been validated and identity-based connections for AzureWebJobsStorage have become generally available, identity will become the default mode for AzureWebJobsStorage. This is intended to move away from shared key authorization, which has been the current mode “the technology behemoth elaborated further.

The post Critical flaw in Azure Storage Account Keys design could allow easy hack appeared first on Information Security Newspaper | Hacking News.

They were able to attack two vulnerabilities without needing any authentication on the service (Azure Functions and Azure Digital Twins). This gave them the ability to make requests in the name of the server even though it did not own an Azure account.

The vulnerabilities in Azure SSRF that were discovered allowed an attacker to scan local ports, find new services, endpoints, and files. This provided valuable information on potentially vulnerable servers and services to exploit for initial entry, as well as the location of information that could be targeted.
SSRF vulnerabilities are particularly dangerous due to the fact that if attackers are able to access the host’s IMDS (Cloud Instance Metadata Service), this exposes detailed information on instances. This information includes the hostname, security group, MAC address, and user-data, and it could potentially allow attackers to retrieve tokens, move to another host, and execute code (RCE).

A server-side request forgery, also known as SSRF, is a web security vulnerability that enables an attacker to abuse a server-side application by making requests to read or update internal resources as well as submit data to external sources. This type of vulnerability is known as a server-side request forgery.

Server-Side Request Forgery (SSRF) attacks often fall into one of these three categories:

Blind SSRF is a sort of SSRF attack that takes place when an attacker is able to influence a server to make requests, but the attacker does not get the answer that the server sends back to them. Because of this, determining whether or not the attack was effective is much more difficult.
Semi-Blind SSRF is a form of SSRF attack that is very similar to Blind SSRF. The only difference is that the attacker is able to view part of the answer from the server, such as the response headers or the status code. This may provide the attacker the ability to obtain some limited information about the system they are attacking.
Non-Blind SSRF, also known as Full SSRF, is a subtype of SSRF attack that takes place when an attacker has the ability to control a server in order to send requests and get the whole answer from the server. This gives the attacker the ability to learn more about the system they are targeting and gives them the opportunity to perhaps conduct other attacks.
The four SSRF vulnerabilities that we found all fall into the third category, which is known as Full SSRF (sometimes referred to as Non-blind SSRF). To give you an idea of how easily these vulnerabilities can be exploited, Non-blind SSRF flaws can be leveraged in a variety of different ways, such as SSRF via XXE, SSRF via SVG file, SSRF via Proxy, SSRF via PDF Rendering, SSRF via vulnerable query string in the URL, and many more. These are just some of the ways that these vulnerabilities can be exploited.

It is essential to keep in mind that each and every SSRF vulnerability may be exploited to get unauthorized access to sensitive information or to launch further attacks against a target. This is the case regardless of the kind of SSRF attack that is being deployed. For this reason, it is essential for businesses to take the necessary precautions to protect their servers and networks against the kinds of attacks described above.

They were not successful in gaining access to any of the IMDS endpoints because Microsoft had implemented a variety of SSRF defenses, one of which was the environment variable known as X-IDENTITY-HEADER. However, even in the event that an attacker was unable to access the IMDS services, there was still a significant amount of potential harm that they might do, as was previously discussed.

After bringing Microsoft’s attention to the security flaws, the company moved quickly to fix them.

The post Four server-side request forgery (SSRF) vulnerabilities impacting different Azure services appeared first on Information Security Newspaper | Hacking News.

The technological giant is in the process of recovering the deleted information

The shut in Azure service last January 29 caused unheard damage. According to network security and ethical hacking experts from the International Institute of Cyber Security, the incident caused the deletion of the databases of some of the users of this service. 

The incident affected some Azure SQL databases that use custom KeyVault keys for the Transparent Data Encryption (TDE), according to the incident report received by affected users. Some internal codes accidentally deleted these Azure portal databases, forcing Microsoft to restore customer data from a record stored in the system, although the databases remained offline for five minutes.

According to network security specialists, due to the incident product orders and other data warehouse updates during that five-minute period were lost.

The note received by users explained that the incident occurred automatically while a DNS error was present that blocked access to Microsoft 365 accounts to more than half of the service customers in the cloud: “An automated process designed to enable when custom keys are removed from KeyVault, it caused inadvertent database deletion”.

“We are trying to restore a copy of these databases; the restored databases will be located on the same server as the original database. We ask users to try to identify whether transactions unregistered in this five-minute period could affect their processes or applications outside of the compromised databases”. 

Some affected users have been bothered by this incident on social networks. On Twitter, for example, in the face of multiple user posts reporting Azure’s flaws, the company began responding to tweets with an automated message that briefly describes the incident.

According to network security specialists, Transparent Data Encryption is designed to protect Microsoft Azure’s SQL databases against “multiple malicious activities”; however, this occasion the security measure could not against the malicious script executed during the fall in the Azure service.

The post Check your Microsoft Azure database; some of them were mistakenly deleted appeared first on Information Security Newspaper | Hacking News.