Back

4 Risk-Based Vulnerability Management Realities Cybersecurity Leaders Must Face

Let’s start by defining the goal: a risk-based vulnerability management program. A risk-based vulnerability management program focuses on finding and fixing the vulnerabilities based on the damage it could cause if exploited and how likely exploitation is… in other words, the ones that pose the greatest risk to your business.  

Even the majority of board members across the globe view cybersecurity as a business risk versus a technology risk, according to a survey from Gartner. It makes sense why most security leaders are working hard to shift to this model as organizations are swamped with vulnerabilities – notably, high-severity, business critical vulnerabilities

Last year, a record number of critical vulnerabilities were disclosed to the National Institute of Standards and Technology (NIST): 10,342 (source: Security Magazine). A check-the-box, compliance-driven vulnerability management program will no longer cut it. As serious vulnerabilities are on the rise, it’s up to us to determine which are fixed first. 

Before you can successfully implement a risk-based program, there are four realities you must face: 

  1. You will have security vulnerabilities that you will never address 
  2. CVSS scores do not represent business risk 
  3. To have an effective risk-based program, we have to lessen the gap between IT and business  
  4. We must adopt a “we’re all in this together” mentality to tackle cybersecurity risk 

In this blog post, I’ll dig into each of these realities and the steps you can take to come to terms with and, in many cases, overcome them. First, a quick primer on risk scoring, a key component to risk-based vulnerability management

An introduction to risk scoring 

At NetSPI, one way we’re helping our clients address these challenges, or “realities” as I refer to in this article, is through risk scoring. In simple terms, a risk score quantifies risk for more accurate and efficient vulnerability remediation prioritization.

Risk Overview Dashboard

If you’re a NetSPI customer, you may have noticed the new Risk Overview Dashboard in Resolve™, our PTaaS platform. The dashboard features an aggregate risk score, composite risk scores for applications, networks, and cloud, an industry benchmark, the number of open critical vulnerabilities, the riskiest projects or assets, the top 10 highest risks, and more. 

NetSPI’s Risk Score is calculated based on transparent methodology that considers vulnerability risk (impact, likelihood, environmental modifiers, and temporal modifiers), threat actor risk, remediation risk, and industry risk to quantify risk levels on any given asset, project, network, or an entire organization. Read more about NetSPI’s risk score methodology in our whitepaper, How to Use Risk Scoring to Propel Your Risk-Based Vulnerability Management Program Forward

Risk scores can be used for remediation prioritization, resource allocation, cybersecurity spend validation, risk management tracking, industry benchmarking, and more. I like to think of it as a behind-the-scenes program manager for risk-based vulnerability management programs – continue reading to learn why. 

You will have security vulnerabilities that you will never address 

It is unrealistic to assume that any organization is vulnerability-free. Once you come to terms with this, risk’s role in vulnerability management becomes a lot clearer. 

You can have the same vulnerability across 6 different assets, but is it wise to fix them all at once? 

Traditionally, this is how many have approached vulnerability management, but the answer is, in most situations, no. It is important to focus on the system with the most risk versus solving the vulnerability across all systems. This holistic approach to vulnerability management is key as it allows you to incorporate business risk into your decisions. 

When you start to factor business risk into the mix, you can identify which assets or systems are most likely to be taken advantage of AND create the most damage if exploited. Then, prioritize remediation, budget, and time accordingly.  

Risk scoring can help expedite this decision-making process. The higher your risk score, the higher priority that system, asset, network, finding, project, etc. And some with very low risk may not warrant remediation at all. 

CVSS scores do not represent business risk 

A Common Vulnerability Scoring System (CVSS) score alone cannot provide a full picture of business risk, but it is a strong starting point for the basis of a risk score. CVSS scores are helpful for vulnerability-specific ratings, but they do not incorporate aggregate factors such as active threat intelligence or correlation to other penetration testing data points.  

Additionally, CVSS scores follow a standard formula, regardless of the size, industry, or other business factors, leaving little to no room for customization. This results in organizations not getting the complete picture of a vulnerability’s potential impact.  

CVSS scores are often used as a metric for return on security investments. I believe they should not be used as such. As an alternative, if you are utilizing a true risk program, risk scoring can be used as a quantitative metric to represent business risk across your organizations. 

To have an effective risk-based program, we have to lessen the gap between IT and business  

There’s a knowledge gap between IT and the business and we cannot achieve a risk-based vulnerability management program until that gap shrinks.  

In the healthcare industry, risk alignment between IT and the business is critical. The business is patient health and safety and its up to security and IT leaders to help the business understand how it directly impacts and protects patient health and safety, whether that’s through protecting Personal Health Information (PHI) or saving lives through ransomware prevention activities. 

This is the same with any business. You have to find common ground between what you’re doing from an IT perspective to show how you’re a part of the business and are critical in the day-to-day operations. 

A simple shift in the way we talk about cybersecurity to business leaders could make a massive difference. A risk-forward approach is key. Here are two examples of this: 

🚫 What does it cost us to protect the business

🚫 How do we secure our technical systems

✔️ What will it cost us if we don’t
 

✔️ How do we secure our business processes

We must adopt a “we’re all in this together” mentality to tackle cybersecurity risk 

Industry benchmarking is an incredibly powerful tool to communicate your risk-based vulnerability management program successes and progress.  

However, we must not fall into the pattern of comparing our programs against others in our industry. There is an analogy that we need to retire. It’s used so often that Red Bull even uses it as the premise for one of its most popular commercials. It’s the idea that, if you’re better than your industry peers, you’re less likely to fall victim to a cyberattack. 

It is important to remember that we’re all fighting the same fight: to eliminate or alleviate the cybersecurity risks that lurk not only in specific industries but across all organizations. We need to work together, not against one another, for the greater good – and a risk-based vulnerability management program is a step in the right direction. Even auditors and cyber insurers are recognizing this shift towards risk-based programs to steer security programs towards maturity. 

With these four realities addressed, there’s no better time to get started. Focus your attention on high-risk vulnerabilities, use risk scores to communicate business risk, shrink the gap between IT and business, and work together to make the shift to a risk-based vulnerability management program a reality for your organization.  

Connect with NetSPI to learn how to achieve risk-based vulnerability management with PTaaS
Back

NetSPI Practice Director Publishes Azure Penetration Testing Book for Ethical Hackers

Co-authored by two of the world’s foremost experts on Azure cybersecurity, the book explores how to perform successful pentesting and risk assessment of Microsoft Azure environments.

Minneapolis, Minnesota  –  NetSPI, the leader in enterprise penetration testing and attack surface management, today announced the launch of Penetration Testing Azure for Ethical Hackersa book co-authored by NetSPI practice director Karl Fosaaen and global cloud security consultant David Okeyode. Written to provide security professionals hands-on lessons and tips for successful Azure penetration testing, the book serves as a resource for industry professionals to simulate real-world Azure attacks and learn how to better identify vulnerabilities.  

To keep sensitive data secure as businesses migrate from on-premise environments to the cloud, pentesting has become a necessity for all organizations operating in Microsoft Azure. This investment ensures that organizations have consistent visibility into security gaps in cloud infrastructures, and provides actionable guidance to remediate vulnerabilities and improve organizations’ overall cloud security posture. 

“The cloud is top of mind for nearly all of today’s security professionals and will continue to be a vital aspect to IT spend,” said author Karl Fosaaen, practice director at NetSPI. “This book provides a digestible framework for professionals of all levels to better understand pentesting within Azure environments. It offers hands-on exercises for readers to test their skills and learn key pentesting techniques that are crucial to successfully assess Azure environments in today’s ecosystem.”  

Penetration Testing Azure for Ethical Hackers takes readers through the prerequisites for Azure penetration testing, while also giving step-by-step instructions on how to set up a pentesting lab. Readers will also learn how to simulate an attack on Azure assets –– demonstrating the techniques and methodologies an attacker uses to gain persistent access to cloud environments. 

“With the rapid acceleration to cloud-based environments and increased gaps in Azure security implementations, penetration testing is becoming an increasingly important skill for security professionals to utilize,” said David Okeyode, co-author and EMEA chief technology officer, Azure Cloud at Palo Alto Networks. “IT teams will come to understand how hackers attack resources hosted within Azure, learn how to effectively protect their environments from these threats, and extend their current pentesting skill sets and capabilities.” 

Order Penetration Testing Azure for Ethical Hackers now on Amazon. To learn more about NetSPI’s Azure cloud penetration testing capabilities, visit the NetSPI website

To see Azure penetration testing techniques in action, read our technical blog detailing Karl’s latest Microsoft Azure cloud vulnerability finding: CVE-2021-42306.

About NetSPI

NetSPI is the leader in enterprise security testing and attack surface management, partnering with nine of the top 10 U.S. banks, three of the world’s five largest healthcare companies, the largest global cloud providers, and many of the Fortune® 500. NetSPI offers Penetration Testing as a Service (PTaaS) through its Resolve™ penetration testing and vulnerability management platform. Its experts perform deep dive manual penetration testing of application, network, and cloud attack surfaces, historically testing over 1 million assets to find 4 million unique vulnerabilities. NetSPI is headquartered in Minneapolis, MN and is a portfolio company of private equity firms Sunstone Partners, KKR, and Ten Eleven Ventures. Follow us on FacebookTwitter, and LinkedIn.

Media Contacts:
Tori Norris, NetSPI 
victoria.norris@netspi.com 
(630) 258-0277 

Amanda Echavarri, Inkhouse for NetSPI 
netspi@inkhouse.com 
(978) 201-2510

Back

The Register: Microsoft squashes Azure privilege-escalation bug

On November 23, 2021, NetSPI Director Karl Fosaaen was featured in an article written by Iain Thomson for The Register. Read the full article below or online here.

Microsoft has fixed a flaw in Azure that, according to the infosec firm that found and privately reported the issue, could be exploited by a rogue user within an Azure Active Directory instance “to escalate up to a Contributor role.”

“If access to the Azure Contributor role is achieved, the user would be able to create, manage, and delete all types of resources in the affected Azure subscription,” NetSPI said of the vulnerability, labeled CVE-2021-42306.

Essentially, an employee at a company using Azure Active Directory, for instance, could end up exploiting this bug to ruin an IT department or CISO’s month. Microsoft said last week it fixed the problem within Azure:

Some Microsoft services incorrectly stored private key data in the (keyCredentials) property while creating applications on behalf of their customers.

We have conducted an investigation and have found no evidence of malicious access to this data.

Microsoft Azure services affected by this issue have mitigated by preventing storage of clear text private key information in the keyCredentials property, and Azure AD has mitigated by preventing reading of clear text private key data that was previously added by any user or service in the UI or APIs.

“The discovery of this vulnerability,” said NetSPI’s Karl Fosaaen, who found the security hole, “highlights the importance of the shared responsibility model among cloud providers and customers. It’s vital for the security community to put the world’s most prominent technologies to the test.”

Back

IoT: Great Holiday Gift or Network Security Nightmare?

While the best part of the holidays is spending time with family and friends, giving or receiving a new smart device can often be the icing on the cake for people of all ages. A recent Consumer Technology Association study noted that technology sales are expected to hit $142.5 billion this holiday season – a record high from the last few years.  

However, with the pandemic creating a distributed workforce where employees log onto corporate networks at home, these fun holiday gifts may be the next big network security risk – for both employees’ personal lives and corporate networks.  

Companies need to better prepare for security vulnerabilities associated with the holiday season, while more broadly achieving a better understanding of how personal and corporate networks are blending in the modern work environment. To prepare, employees need to be educated on the risks smart devices bring to their home networks and IT/security leaders need to bolster their systems to ensure they remain secure while employees work from home.  

Understand the IoT security risks for remote workers 

Network risks are evolving. Over the last two years alone, more people have set up multiple devices that connect to a single home network, including corporate-issued computers and tablets. With so many devices already in play, and more to come as gifts this holiday season, the attack surface has grown exponentially.  

The problem with connected tech holiday gifts 

Some of the most popular technology gifts come equipped with Bluetooth and Wi-Fi, cameras, and geo-mapping. A popular gift, Tile-like tracking devices meant to help consumers find everyday items that are easily lost, has created conversation and speculation within the security industry over the years. But the threat has heightened, as an Apple integration now allows these types of devices – including Apple’s own AirTag – to be added and tracked on its “Find Me” feature. If compromised, an outside party could begin tracking the user’s location without their permission and monitor living patterns to exploit the information and lure them into a phishing attack or other breach. 

Additionally, through a partnership with Amazon, Tile can now integrate with Alexa and other Amazon devices to detect if a Tile is nearby. With this feature, malicious actors could find any Tile in the area, hack into its GPS functionality, track its location, and notify the Tile network of its name, location, etc. within a certain radius – opening home devices to potential exploitation. 

The same threats lie within additional ‘smart’ gifts. Robot vacuums, regardless of the brand, are connected to home networks and also connect to the internet – and integrate with other home automation products. This extension of connectivity creates a complex system that is more prone to attacks because it has greater potential for flaws and vulnerabilities. When you integrate a camera onto these devices, the risks only grow. Threat actors could easily monitor users’ movements to understand daily patterns and even craft a blueprint of their home. 

How to solve for these vulnerabilities at home 

With so many new gadgets and technology gifts on the market, many main players in this space are not doing their diligence to ensure the proper security precautions are in place – especially since it’s an unregulated industry and manufacturing companies often prioritize development over security to meet increasing demands. As you install more IoT devices and get new gadgets for the holidays, consider putting these devices on a guest network. This will separate your at-home devices from your corporate computer and technology, limiting the potential attack surface that malicious actors can exploit. 

If an attack does arise, using a guest network makes it easier to track and pinpoint the exact location of the breach, while limiting the potential threat to your corporate or home network. It’s also a best practice to pick one home automation kit and standardize it across all the technology in your house so all items will seamlessly integrate into that one system.  

Understand and prevent corporate network vulnerabilities  

The transition to remote work, spurred by the pandemic, brought all corporate devices into employees’ homes and opened up a can of worms for potential vulnerabilities – home office networks are said to be 3.5 times more likely to be attacked than corporate networks. Further, there is currently a misconception about which systems and software can securely switch between corporate and at home networks, meaning employees have potentially opened their corporate networks to security risks dating back to when they initially took their office gear home in Spring 2020. Knowing this, how can IT and security teams prepare for the holiday gift season, where even more tech will be added to the mix? 

Audit your security tools early on 

To better understand, assess, and manage how employees are accessing company networks during the holidays and to work from home, companies should set up regular tests of their systems. Having a security testing program set in place – prior to the holidays – can help to identify any vulnerabilities within the corporate network quickly and efficiently. It can also open IT and security teams’ eyes to which devices are vulnerable when used at home on personal networks. It’s important for companies to understand where vulnerabilities lie and make sure their systems and devices are secure year-round, but even more so during the holidays when the majority of staff is working remotely or taking time off.  

NetSPI is the leader in network penetration testing – work with our experts!

Educate! 

Often, security breaches are caused by a general lack of awareness within employee bases. Corporations should develop mandatory training programs that bring potential vulnerabilities to light, and teach their workforce how to monitor, prevent and report potential dangers. Training programs should include a specific lesson on the dangers of smart devices and working on home networks – consider timing this specific training in late-November, early-December, before the holiday season kicks off.  

The holidays should be a time where all employees can recharge and spend time with family, without worrying about work. The onus is on enterprises to prepare their workforce for potential IT threats, while also taking proactive measures to prevent potential vulnerabilities in their network. Smart tech gifts aren’t going away, but with proper protocols in place, IT teams, company leadership, and the broader employee network can all enjoy time off without the risk of a breach.  

Back

Security Affairs: Microsoft addresses a high-severity vulnerability in Azure AD

On November 18, 2021, NetSPI Director Karl Fosaaen was featured in an article written by Pierluigi Paganini for Security Affairs. Read the full article below or online here.

Microsoft has recently addressed an information disclosure vulnerability, tracked as CVE-2021-42306, affecting Azure AD.

“An information disclosure vulnerability manifests when a user or an application uploads unprotected private key data as part of an authentication certificate keyCredential  on an Azure AD Application or Service Principal (which is not recommended). This vulnerability allows a user or service in the tenant with application read access to read the private key data that was added to the application.” reads the advisory published by Microsoft. “Azure AD addressed this vulnerability by preventing disclosure of any private key values added to the application. Microsoft has identified services that could manifest this vulnerability, and steps that customers should take to be protected. Refer to the FAQ section for more information.”

The vulnerability was discovered by Karl Fosaaen from NetSPI, it received a CVSS score of 8.1. Fosaaen explained that due to a misconfiguration in Azure, Automation Account “Run as” credentials (PFX certificates) ended up being stored in clear text in Azure AD and anyone with access to information on App Registrations can access them.

An attacker could use these credentials to authenticate as the App Registration, typically as a Contributor on the subscription containing the Automation Account.

“This issue stems from the way the Automation Account “Run as” credentials are created when creating a new Automation Account in Azure. There appears to have been logic on the Azure side that stores the full PFX file in the App Registration manifest, versus the associated public key.” reads the analysis published by NetSPI.

An attacker can exploit this flaw to escalate privileges to Contributor of any subscription that has an Automation Account, then access resources in the affected subscriptions, including sensitive information stored in Azure services and credentials stored in key vaults.

The issue could be potentially exploited to disable or delete resources and take entire Azure tenants offline.

Microsoft addressed the flaw by preventing Azure services from storing clear text private keys in the keyCredentials property and by preventing users from reading any private key data that has been stored in clear text.

Back

ChannelPro Network: Azure Active Directory (AD) KeyCredential Property Information Disclosure

On November 18, 2021, NetSPI Director Karl Fosaaen was featured in an article written by Jay Ferron for ChannelPro Network. Read the full article below or online here.

Microsoft recently mitigated an information disclosure issue, CVE-2021-42306, to prevent private key data from being stored by some Azure services in the keyCredentials property of an Azure Active Directory (Azure AD) Application and/or Service Principal, and prevent reading of private key data previously stored in the keyCredentials property.

The keyCredentials property is used to configure an application’s authentication credentials. It is accessible to any user or service in the organization’s Azure AD tenant with read access to application metadata.

The property is designed to accept a certificate with public key data for use in authentication, but certificates with private key data could have also been incorrectly stored in the property. Access to private key data can lead to an elevation of privilege attack by allowing a user to impersonate the impacted Application or Service Principal.

Some Microsoft services incorrectly stored private key data in the (keyCredentials) property while creating applications on behalf of their customers. We have conducted an investigation and have found no evidence of malicious access to this data.

Microsoft Azure services affected by this issue have mitigated by preventing storage of clear text private key information in the keyCredentials property, and Azure AD has mitigated by preventing reading of clear text private key data that was previously added by any user or service in the UI or APIs.

As a result, clear text private key material in the keyCredentials property is inaccessible, mitigating the risks associated with storage of this material in the property.

As a precautionary measure, Microsoft is recommending customers using these services take action as described in “Affected products/services,” below. We are also recommending that customers who suspect private key data may have been added to credentials for additional Azure AD applications or Service Principals in their environments follow this guidance.

Affected products/services

Microsoft has identified the following platforms/services that stored their private keys in the public property. We have notified customers who have impacted Azure AD applications created by these services and notified them via Azure Service Health Notifications to provide remediation guidance specific to the services they use.

Product/ServiceMicrosoft’s MitigationCustomer impact assessment and remediation
Azure Automation uses the Application and Service Principal keyCredential APIs when Automation Run-As Accounts are createdAzure Automation deployed an update to the service to prevent private key data in clear text from being uploaded to Azure AD applications. Run-As accounts created or renewed after 10/15/2021 are not impacted and do not require further action.Automation Run As accounts created with an Azure Automation self-signed certificate between 10/15/2020 and 10/15/2021 that have not been renewed are impacted. Separately customers who bring their own certificates could be affected. This is regardless of the renewal date of the certificate.

To identify and remediate impacted Azure AD applications associated with impacted Automation Run-As accounts, please navigate to this Github Repo.

In addition, Azure Automation supports Managed Identities Support (GA announced on October 2021). Migrating to Managed Identities from Run-As will mitigate this issue. Please follow the guidance here to migrate.
Azure Migrate service creates Azure AD applications to enable Azure Migrate appliances to communicate with the service’s endpoints.Azure Migrate deployed an update to prevent private key data in clear text from being uploaded to Azure AD applications.

Azure Migrate appliances that were registered after 11/02/2021 and had Appliance configuration manager version 6.1.220.1 and above are not impacted and do not require further action.
Azure Migrate appliances registered prior to 11/02/2021 and/or appliances registered after 11/02/2021 where auto-update was disabled could be affected by this issue.

To identify and remediate any impacted Azure AD applications associated with Azure Migrate appliances, please navigate to this link.
Azure Site Recovery (ASR) creates Azure AD applications to communicate with the ASR service endpoints.Azure Site Recovery deployed an update to prevent private keydata from being uploaded to Azure AD applications. Customers using Azure Site Recovery’s preview experience “VMware to Azure Disaster Recovery” after 11/01/2021 are not impacted and do not require further action.Customers who have deployed and registered the preview version of VMware to Azure DR experience with ASR before 11/01/2021 could be affected.

To identify and remediate the impacted AAD Apps associated with Azure Site Recovery appliances, please navigate to this link.
Azure AD applications and Service Principals [1]Microsoft has blocked reading private key data as of 10/30/2021.Follow the guidance available at aad-app-credential-remediation-guide to assess if your application key credentials need to be rotated. The guidance walks through the assessment steps to identify if private key information was stored in keyCredentials and provides remediation options for credential rotation.

[1] This issue only affects Azure AD Applications and Service Principals where private key material in clear text was added to a keyCredential. Microsoft recommends taking precautionary steps to identify any additional instances of this issue in applications where you manage credentials and take remediation steps if impact is found.

What else can I do to audit and investigate applications for unexpected use?

Additionally, as a best practice, we recommend auditing and investigating applications for unexpected use:

  • Audit the permissions that have been granted to the impacted entities (e.g., subscription access, roles, OAuth permissions, etc.) to assess impact in case the credentials were exposed. Refer to the Application permission section in the security operations guide.
  • If you rotated the credential for your application/service principal, we suggest investigating for unexpected use of the impacted entity especially if it has high privilege permissions to sensitive resources. Additionally, review the security guidance on least privilege access for apps to ensure your applications are configured with least privilege access.
  • Check sign-in logs, AAD audit logs and M365 audit logs, for anomalous activity like sign-ins from unexpected IP addresses.
  • Customers who have Microsoft Sentinel deployed in their environment can leverage notebook/playbook/hunting queries to look for potentially malicious activities. Look for more guidance here.
  • For more information refer to the security operations guidance.

Part of any robust security posture is working with researchers to help find vulnerabilities, so we can fix any findings before they are misused. We want to thank Karl Fosaaen of NetSPI who reported this vulnerability and Allscripts who worked with the Microsoft Security Response Center (MSRC) under Coordinated Vulnerability Disclosure (CVD) to help keep Microsoft customers safe.

Back

Redmond: Microsoft Fixes Azure Active Directory Issue Exposing Private Key Data

On November 18, 2021, NetSPI Director Karl Fosaaen was featured in an article written by Kurt Mackie for Redmond. Read the full article below or online here.

Microsoft announced on Wednesday that it fixed an Azure Active Directory private key data storage gaffe that affects Azure application subscribers, but affected organizations nonetheless should carry out specific assessment and remediation tasks.

Affected organizations were notified via the Azure Service Health Notifications message center, Microsoft indicated.

“We have notified customers who have impacted Azure AD applications created by these services and notified them via Azure Service Health Notifications to provide remediation guidance specific to the services they use.”

The applications requiring investigation include Azure Automation (when used with “Run-As Accounts“), Azure Migrate, Azure Site Recovery, and Azure AD Applications and Service Principals. Microsoft didn’t find evidence that the vulnerability was exploited, but advised organizations to conduct audits and investigate Azure apps for any permissions that may have been granted.

Microsoft also urged IT pros to enforce least-privilege access for apps and check the “sign-in logs, AAD audit logs and M365 audit logs for anomalous activity like sign-ins from unexpected IP addresses.”

Private Key Data Exposed

The problem, in essence, was that Microsoft’s Azure app installation processes were including private key data in a property used for public keys. The issue was initially flagged as CVE-2021-42306, an information disclosure vulnerability associated with Azure AD’s keyCredentials property. Any user in an Azure AD tenancy can read the keyCredentials property, Microsoft’s announcement explained:

The keyCredentials property is used to configure an application’s authentication credentials. It is accessible to any user or service in the organization’s Azure AD tenant with read access to application metadata.

The keyCredential’s property is supposed to just work with public keys, but it was possible to store private key data in it, too, and that’s where the Microsoft Azure app install processes blundered.

“Some Microsoft services incorrectly stored private key data in the (keyCredentials) property while creating applications on behalf of their customers,” Microsoft explained.

The Microsoft Security Response Center (MSRC) credited the discovery of the issue to “Karl Fosaaen of NetSPI who reported this vulnerability and Allscripts who worked with the Microsoft Security Response Center (MSRC) under Coordinated Vulnerability Disclosure (CVD) to help keep Microsoft customers safe,” the announcement indicated. 

Contributor Role Rights

The magnitude of the problem was explained in a NetSPI press release. NetSPI specializes in penetration testing and attack surface reduction services for organizations.

An exploit of the CVE-2021-42306 vulnerability could give an attacker Azure Contributor role rights, with the ability to “create, manage, and delete all types of resources in the affected Azure subscription,” NetSPI explained. An attacker would have access to “all of the resources in the affected subscriptions,” including “credentials stored in key vaults.”

NetSPI’s report on the vulnerability, written by Karl Fosaaen, NetSPI’s practice director, described the response by the MSRC as “one of the fastest” he’s seen. Fosaaen had initially sent his report to the MSRC on Oct. 7, 2021.

Fosaaen advised following MSRC’s advice, but added a cautionary note.

“Although Microsoft has updated the impacted Azure services, I recommend cycling any existing Automation Account ‘Run as’ certificates,” he wrote. “Because there was a potential exposure of these credentials, it is best to assume that the credentials may have been compromised.” 

Microsoft offers a script from this GitHub page that will check for affected apps, as noted by Microsoft Program Manager Merill Fernando in this Twitter post

Back

Information Security Newspaper: Very Critical Information Disclosure Vulnerability in Azure Active Directory (AD). Patch Immediately

On November 18, 2021, NetSPI Director Karl Fosaaen was featured in an article written by Octavio Mares for Information Security Newspaper. Read the full article below or online here.

This week, Microsoft reported the detection of a sensitive information leak vulnerability that affects many Azure Active Directory (AD) deployments. The flaw was tracked as CVE-2021-42306 and received a score of 8.1/10 according to the Common Vulnerability Scoring System (CVSS).

According to the report, incorrect configuration in Azure allows “Run As” credentials in the automation account to be stored in plain text, so any user with access to application registration information could access this information, including threat actors.

CVE-2021-42306 CredManifest: App Registration Certificates Stored in Azure Active Directory

The flaw was identified by researchers at cybersecurity firm NetSPI, who mention that an attacker could exploit this condition to perform privilege escalation on any affected implementation. The risk is also present for credentials stored in key vaults and any information stored in Azure services, experts say.

Apparently, the flaw is related to the keyCredentials property, designed to configure authentication credentials for applications. Microsoft said: “Some Microsoft services incorrectly store private key data in keyCredentials while building applications on behalf of their customers. At the moment there is no evidence of malicious access to this data.”

The company notes that the vulnerability was fixed by preventing Azure services from storing private keys in plain text in keyCredentials, as well as preventing users from accessing any private key data incorrectly stored in this format: “Private keys in keyCredentials are inaccessible, which mitigates the risk associated with storing this information,” Microsoft concludes.

Microsoft also mentions that all Automation Run As accounts that were created with Azure Automation certificates between October 15, 2020 and October 15, 2021 are affected by this flaw. Azure Migrate services and customers who deployed VMware preview in the Azure disaster recovery experience with Azure Site Recovery (ASR) could also be vulnerable.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

Back

The Stack: “Keys to the cloud” stored in plain text in Azure AD in major hyperscaler blooper

On November 18, 2021, NetSPI Practice Director Karl Fosaaen was featured in an article on The Stack. Read the full article below or online here.

A critical Azure Active Directory vulnerability (CVE-2021-42361) left user credentials stored in easily accessible plain text – a bug that could have let attackers make themselves a contributor to the affected Azure AD subscription, creating, managing and deleting resources across the cloud-based IAM service; which, abused, hands a potentially terrifying amount of control to any bad actor who’s gained access.

The Azure Active Directory vulnerability resulted in private key data being stored in plaintext by four key Azure services in the keyCredentials property of an Azure AD application. (The keyCredentials property is used to configure an application’s authentication credentials. It is accessible to any user or service in the organization’s Azure AD tenant with read access to application metadata, Microsoft noted in its write-up.)

Azure Automation, Azure Migrate, Azure Site Recovery and Azure applications and Service Principals were all storing their private keys visibily in the public property Microsoft admitted.

“Automation Account ‘Run as’ credentials (PFX certificates) were being stored in cleartext, in Azure Active Directory (AAD). These credentials were available to anyone with the ability to read information about App Registrations (typically most AAD users)” said attack surface management specialist NetSPI.

The bug was spotted and reported by security firm NetSPI’s practice director Karl Fosaaen.

(His technically detailed write-up can be seen here.)

Microsoft gave it a CVSS score of 8.1 and patched it on November 17 in an out-of-band security update.

By selecting the display name, we can then see the details for the App Registration and navigate to the “Manifest” section. Within this section, we can see the “keyCredentials”.

Impacted Azure services have now deployed updates that prevent clear text private key data from being stored during application creation, and Azure AD deployed an update that prevents access to private key data that has previously been stored. NetSPI’s Fosaaen warned however that “although Microsoft has updated the impacted Azure services, I recommend cycling any existing Automation Account ‘Run as’ certificates. Because there was a potential exposure of these credentials, it is best to assume that the credentials may have been compromised.”

There’s no evidence that the bug has been publicly exploited and it would require basic authorisation, but for a motivated attacker it would have represented a significant weapon in their cloud-exploitation arsenal and raises questions about QA at Microsoft given the critical nature of the exposure.

Microsoft described the Azure Active Directory vulnerability in its security update as “an information disclosure vulnerability [that] manifests when a user or an application uploads unprotected private key data as part of an authentication certificate keyCredential  on an Azure AD Application or Service Principal….

“This vulnerability allows a user or service in the tenant with application read access to read the private key data that was added to the application” it added.

In a separate blog by Microsoft Security Response Center the company noted that “access to private key data can lead to an elevation of privilege attack by allowing a user to impersonate the impacted Application or Service Principal” — something illustrated and automated by NetSPI’s Karl Fosaaen.

It’s not Azure’s first serious security issue this year: security researchers at Israel’s Wix in August 2021 found a critical vulnerability in its flagship CosmosDB database that gave them full admin access for major Microsoft customers including several Fortune 500 multinationals. They warned at the time that the “series of flaws in a Cosmos DB feature created a loophole allowing any user to download, delete or manipulate a massive collection of commercial databases, as well as read/write access to the underlying architecture of Cosmos DB.”

Back

SecurityWeek: Microsoft Informs Users of High-Severity Vulnerability in Azure AD

On November 18, 2021, NetSPI was featured in an article written by Ionut Arghire for SecurityWeek. Read the full article below or online here.

Microsoft on Wednesday informed customers about a recently patched information disclosure vulnerability affecting Azure Active Directory (AD).

Tracked as CVE-2021-42306 (CVSS score of 8.1), the vulnerability exists because of the manner in which Automation Account “Run as” credentials are created when a new Automation Account is set up in Azure.

Due to a misconfiguration in Azure, Automation Account “Run as” credentials (PFX certificates) ended up being stored in clear text in Azure AD and could be accessed by anyone with access to information on App Registrations. An attacker could use these credentials to authenticate as the App Registration.

Security researchers with enterprise penetration testing firm NetSPI, who identified the vulnerability, explain that an attacker could leverage the bug to escalate privileges to Contributor of any subscription that has an Automation Account, and access resources in the affected subscriptions.

“This includes credentials stored in key vaults and any sensitive information stored in Azure services used in the subscription. Or worse, they could disable or delete resources and take entire Azure tenants offline,” the researchers explain.

According to Microsoft, the vulnerability is related to the keyCredentials property, which was designed for configuring authentication credentials for applications, and which accepts a certificate containing public key data for authentication, but which also incorrectly stored such certificates.

“Some Microsoft services incorrectly stored private key data in the (keyCredentials) property while creating applications on behalf of their customers. We have conducted an investigation and have found no evidence of malicious access to this data,” Microsoft says.

The tech giant says it has addressed the bug by preventing Azure services from storing clear text private keys in the keyCredentials property and by preventing users from reading any private key data that has been incorrectly stored in clear text.

“As a result, clear text private key material in the keyCredentials property is inaccessible, mitigating the risks associated with storage of this material in the property,” the company says.

Microsoft also notes that all Automation Run As accounts that have been created using Azure Automation self-signed certificates between October 15, 2020, and October 15, 2021, are affected by the issue. Azure Migrate services and customers who deployed the preview version of VMware to Azure DR experience with Azure Site Recovery (ASR) might also be affected.

Thus, Azure AD customers should cycle through all Automation Account “Run as” certificates to make sure no credentials are exposed.

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X