Microsoft recently reported that they have mitigated a vulnerability that was reported in July by security researchers from Palo Alto. This vulnerability impacts the Azure Container Instances feature that allows azure users to deploy containers without the need for Kubernetes or some sort of Linux VM running the docker software to host the container. It does not affect Azure Kubernetes Service (AKS) nor container software running on virtual machines.
The researchers from Palo Alto who discovered the vulnerability were able to eventually gain access to an entire cluster running multiple container instances. The cluster also had access to docker image registries from other customers. This is the first known attack on a cloud provider to use container escape to gain access to other user’s data or containers. The Azure container instances backend used code that had not been updated to patch a known vulnerability. Unfortunately, there is no way to know ahead of time which Azure ACI users or organizations leverage the same cluster as an attacker’s container, however, an attacker could repeatedly deploy malicious containers to find clusters have their targets containers or simply steal sensitive data from any containers they gain access to.
In a blog post from its security response team, Microsoft said it had fixed the flaw reported by Palo Alto Networks and it had no evidence malicious hackers had abused the technique. However, Microsoft said it had notified customers who shared the same cluster with the researchers and recommended that they change any credentials that may have been exposed to the containers.
“Microsoft’s investigation surfaced no unauthorized access to customer data. Out of an abundance of caution we notified customers with containers running on the same clusters as the researchers via Service Health Notifications in the Azure Portal”.
From the Microsoft vulnerability disclosure:
If you did not receive a notification, no action is required with respect to this vulnerability.
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 Palo Alto Networks who reported this vulnerability and worked with the Microsoft Security Response Center (MSRC) under Coordinated Vulnerability Disclosure (CVD) to help keep Microsoft customers safe.
Which Azure Container Instances accounts were potentially affected?
There is no indication any customer data was accessed due to this vulnerability. Out of an abundance of caution, notifications were sent to customers potentially affected by the researcher activities, advising they revoke any privileged credential that were deployed to the platform before August 31, 2021.
If you did not receive a Service Health Notification, no action is required. The vulnerability is fixed and our investigation surfaced no unauthorized access in other clusters. If you are unsure whether your subscription or organization has received a notification, please contact Azure Support. If you have any concerns, rotating privileged credentials is a good periodic security practice and would be an effective precautionary measure.
The discovery has underscored the importance of shared responsibility between cloud providers and customers for security. It also underscores how important it is to use container security features to limit the potential impact of an attacker gaining access to your container. At minimum I’d recommend:
- Scan your docker images using a managed docker image registry and use tooling to scan your container images for vulnerabilities. Defender for container registries can be integrated with Azure Security Center to scan all images in your registry. It will look at any new images as well as scan images that have been added for the past 30 days.
- Leverage docker features to ensure applications in your container are not running as root (or equivalent)
- Making sure you’re removing all unnecessary binaries from your container images
- Use Azure Monitor to look for changes on your containers for run time deviations. The whole point of containers is that they’re uniform and immutable. If you suddenly see your container spawn a new binary that is unexpected, you should assume it’s compromised, capture forensic information, and remove the container.
For a complete list of security considerations for Azure Container Instances:
Introduction to Azure Defender for container registries
Use Azure Defender for container registries to scan your images for vulnerabilities
Users have taken to Microsoft Office 365’s tools, but many are unaware of free features that come with their accounts — features that would keep them safe.
Organizations have quickly adopted the full-featured set of productivity and collaboration tools offered by Office 365 (O365), which was moved under the Microsoft 365 umbrella this spring. They’re leveraging Microsoft Teams, SharePoint, OneDrive, and other file storage systems to store and collaborate on sensitive documents and data. However, with the exponential increase of usage in the last few months, the platform has become an enticing and fruitful target for attackers of all types.
In 2019, 85% of all incident response investigations conducted by the Kudelski Security Incident Response team started with a compromised Office 365 account. While reviewing the results of those investigations, one thing quickly became apparent: Attackers know the productivity suite better than most IT administrators and defenders.
How Attackers Are Attacking
This year, we saw attackers leverage a multitude of attack techniques, most of which could have been easily prevented by turning on features included with most Office 365 Enterprise plans. As organizations strategize for 2021, it is paramount to know and understand how malicious actors are capitalizing on their knowledge of these environments to compromise, persist in, and exfiltrate data.
Here are the three most common ways attackers are leveraging Microsoft’s platform:
1. Brute Force and Password Stuffing
Credential stuffing is still one of the leading causes of account compromise. Attackers take advantage of the fact that most organizations don’t enable multifactor authentication (MFA), a free feature offered to all Microsoft 365 tenants, which, according to Microsoft, could have prevented 99.9% of account compromises it saw across users’ environments.
The vast majority of “password stuffing” attacks aren’t targeted. Attackers get a hold of a password dump from a third-party source and attempt to “stuff” these passwords into Microsoft 365 login prompts. Such attacks rely heavily on users reusing passwords across software-as-a-service providers and websites, including their corporate accounts.
Another challenge is the “legacy protocol” support. Through this, attackers can brute force MFA-protected accounts by attempting to authenticate via protocols that don’t support MFA, such as SMTP, IMAP, and POP3. These provide an avenue to freely brute-force account passwords without having to deal with further verification prompts. Today, there are at least four different open source tools that abuse these legacy protocols, including LyncSniper (targets Skype for Business), SensePost Ruler (targets Exchange Server), MailSniper (targets Outlook Web Access/Exchange Web Services), and SprayingToolkit (targets Lync/Outlook Web Access).
This problem is compounded by organizations allowing users to reset MFA devices or applications simply through a confirmation link sent to the compromised email accounts. Attackers reset MFA tokens and leverage these newly registered applications to log in to others that rely on Microsoft 365 Single Sign-On, potentially gaining access to more sensitive data.
Organizations should work to limit the usage of legacy protocols with Azure Active Directory conditional access as well as take advantage of the MFA feature to add another layer of security for users.
2. OAuth Consent Grants
Attackers are also phishing users with links to OAuth consent grant screens designed to trick users into granting access to their Microsoft 365 accounts to malicious applications. Those consent screens are real, hosted by Microsoft, and request that users provide access to their email inboxes and other data. Once malicious applications are granted access, attackers have unrestricted access to the accounts without the need for passwords or MFA. Because OAuth 2.0 grants don’t expire, attackers will retain that access until that specific grant is revoked. Even changing a user’s password won’t revoke these tokens automatically.
There are several open source tools that enable attackers to easily create fake applications that need to be considered, including MdSec Office 365 Attack ToolKit and FireEye PwnAuth.
We have seen an uptick in the abuse of OAuth grants. To prevent these attacks, organizations can require that only specific preapproved applications be allowed to leverage OAuth 2.0 or leverage publisher verification, or administrators can choose to limit access to “sensitive” OAuth 2.0 grants.
3. eDiscovery and Microsoft Flow Abuse
Attackers know that the eDiscovery features included in the platform’s security and compliance center can be leveraged to easily identify documents of interest across applications, including Microsoft Teams, SharePoint, OneDrive, and Exchange email servers. They also know that most organizations haven’t even taken the time to turn on audit logging (turned off by default) or aren’t monitoring their Azure Active Directory environments. These organizations won’t be able to detect attackers granting themselves the permissions necessary to leverage eDiscovery tooling.
The productivity suite also grants users access to Microsoft Flow, a workflow automation tool that enables users to automate tasks based on certain triggers. Malicious actors take advantage of the fact that once they gain access to eDiscovery, they can leverage Microsoft Flow and completely automate sensitive document discovery and exfiltration.
Attackers know this platform better than most defenders and have become very effective at compromising tenants easily without having to bypass the multitude of Microsoft-offered security capabilities. Part of the issue is that organizations aren’t taking full advantage of the free features included with their subscriptions. In fact, attackers are abusing Microsoft features that IT administrators aren’t even aware exist.
IT and security teams must know what they have available already and enable all the features that will help them close the door to potential threats.
This article was originally featured in Dark Reading.
Passwords have long been a daily part of our lives, but in today’s modern, cloud-first world the use of passwords alone leaves us increasingly more vulnerable to compromise. Large-scale data breaches are being reported more and more frequently in the media with more than 80% of hacking-related breaches involving compromised or weak credentials.
Traditional password management
Traditionally, we overcame weak passwords by implementing password complexity and expiry policies with the addition of multi-factor authentication (MFA), but these practices were not always user-friendly and were burdensome to manage. Password complexity policies make passwords more predictable and often lead to poor security practices like the old ‘password on a post–it’ scenario. Users will inevitably find the easiest, most convenient way to meet the complexity policy. The latest NIST password guidelines, published under NIST 800-63, recommend against both password complexity and password expiry. Microsoft says that MFA-enabled accounts are 99.9% less likely to be compromised, however, less than 10% of enterprise users use MFA. There is no denying that passwords are the weakest form of authentication and in order to improve our security posture and appropriately secure our digital assets we need to consider a more modern approach to authentication.
A modern approach
Passwordless authentication is a modern approach to authentication that offers improved security and better user experience. While traditional MFA requires something you know (password or PIN), something you have (smart card or token), or something you are (biometric), passwordless authentication adds convenience by replacing the traditional password with something you have – in this case a device or a security key – and also requiring something you are or something you know.
Microsoft currently offers the following three passwordless authentication options:
- Windows Hello for Business
- Microsoft Authenticator app
- FIDO2 security keys
Fast Identity Online or FIDO2 compliant security keys are standards-based cryptographic credentials that are available in many different form factors such as USB keys or NFC-enabled smartcards from several different providers. These are particularly interesting as they allow organizations to choose the technology that best suits their needs and doesn’t have specific hardware and operating system requirements.
Each of the above-mentioned authentication options offers a unique set of pros and cons, giving organizations the ability to use the method that best caters to its unique requirements. Perhaps different user personas within the organization have different needs – for example, requiring fingerprint biometrics for factory workers who use gloves all day wouldn’t be ideal, so it is possible to mix and match these options as needed.
Not a silver bullet
Enabling passwordless authentication in Azure Active Directory is fairly straightforward, however simply enabling the feature doesn’t solve all the problems associated with passwords and this causes much confusion. While passwordless authentication does a great job of straddling the line between security and convenience, it does not (yet) eliminate passwords completely from the environment. Users will still have the option of logging in with their traditional password if they so choose. It is therefore vitally important to take the following actions prior to implementing passwordless authentication:
If you haven’t already implemented MFA, I would strongly recommend that you do. This change is very visible to the user community, it requires communications and end-user training which could take a considerable amount of time in large organizations. While you prepare to introduce MFA into your environment, you can dramatically improve your security posture by enabling MFA for all your privileged accounts. MFA is also a prerequisite for passwordless authentication and if you plan to use the Microsoft Authenticator app option for passwordless authentication you will have a head start since your user devices will already have the app installed.
Reduce user-visible password prompts
Implementing single sign-on (SSO) will help reduce the number of times users are prompted for their password. This will in turn will reduce the likelihood of a user surrendering their credentials during a phishing attack since users who are constantly prompted for login are conditioned to entering their credentials and don’t always take the time to examine the legitimacy of every login form. SSO also requires modern authentication methods and this will expedite the remediation of any applications that still rely on legacy authentication.
Improve your password management practices
Since user passwords are not eliminated entirely, it is important to adopt modern, up to date password guidelines such as NIST 800-63. Self-service password management capabilities should go hand-in-hand with updated password policies. Allowing users to manage and reset their own passwords will help ease the administrative burden.
Consider using tools like Azure AD password protection to ensure that users are not using weak or banned passwords.
Passwords are outdated and cannot be relied on to provide any significant form of security by themselves. Passwordless authentication is a form of multi-factor authentication that is both secure and convenient and can be implemented in different ways based on the needs of the organization. Since passwords are not currently completely eliminated from the environment, it is important that the implementation is accompanied by an up to date password policy.
Read our previous post on Office 365 security here.
Interested in topics like this? Check out these posts on the Kudelski Security Research Blog:
One of the misconceptions about cloud services is that you have to surrender all control when you sign-up. While it is true that you may no longer have racks of servers with blinking lights humming away in your data center, it doesn’t mean that you no longer have any visibility into how your users use and interact with the service.
Office 365 is no exception and the service includes several auditing and reporting features that can be used to track user and administrative activity within a tenant. Unfortunately, there is no singe place to view all audit logs and in some instances this functionality is not enabled by default which causes confusion. The good news is that once enabled, this audit data is available to consume directly from the Security & Compliance Center or Admin Portals without the need for a security information and event management (SIEM) platform.
Office 365 audit logs
The audit information and reports available in Office 365 can be used to effectively manage user experience, mitigate risks, and is required in many instances to fulfill compliance obligations. Audit logging is not enabled by default in Office 365 and must first be turned on in the Security & Compliance Center before audited activities can be searched. There are two main types of activities that are tracked in the unified audit log, these are:
- Admin activities
- User activities
While mailbox audit logging in Exchange Online has been enabled by default since early 2019, only users with E5 licenses will return mailbox audit log events in audit log searches in the Security & Compliance Center. Mailbox audit log entries for users without E5 licenses can also be retrieved after mailbox auditing has been manually enabled on those individual mailboxes.
Azure Active Directory (Azure AD) also provides several reports to help keep track of user sign-in activity and security. Unlike Office 365 auditing, these are enabled by default. It is important to note that it could take 30 minutes to 24 hours after an event occurs for the corresponding audit log record to be returned in the results of an audit log search.
When an audited activity is performed by a user or admin, an audit record is generated and stored in the Office 365 audit log. The length of time that an audit record is retained and searchable depends on your Office 365 or Microsoft 365 enterprise subscription the type of the license that is assigned to a specific user. Similarly, Azure AD activities are maintained in accordance to the Azure AD plan in use.
Logging is an essential part of your cloud service and can help troubleshoot user issues, mitigate risks, and fulfill compliance obligations. Office 365 includes several auditing and reporting features, however not all logging is not enabled by default. The following table provides a summary of some of the most important logging available to Office 365 administrators:
||Enabled by default
||Office 365 Security & Compliance Center
||Office 365 Security & Compliance Center
||Office 365 Security & Compliance Center / Exchange Online
||Yes – requires manual intervention for non-E5 users
||30 days (P1/P2 only)
|Users at Risk
30 days (P1/P2)
30 days (P1/P2)
|Azure MFA Usage