FREE TRAINING Microsoft training for Security Engineers
Secure your systems and protect your data
You’re responsible for the design and implementation of digital security controls, managing access, and protecting your data in cloud networks and hybrid environments. Get the skills and knowledge needed to build your career as a successful Security Engineer. To learn more, go here.
The Mobile Device Security Team at NIST’s National
Cybersecurity Center of Excellence (NCCoE) has published the
second draft of Special Publication 1800-22 Mobile Device Security: Bring
Your Own Device (BYOD) and is seeking the public’s comments on its
contents. Many organizations now support their employees’ use of personal
mobile devices to remotely perform work-related activities.
This increasingly common practice, known as BYOD, provides
employees with increased flexibility to telework and access organizational
information resources. Helping to ensure that an organization’s data is
protected when it is accessed from personal devices, while also protecting the
privacy needs of employees, poses unique challenges and threats.
The goal of this practice guide is to provide an example solution
that helps organizations use both a standards-based approach and commercially
available technologies to help meet their security and privacy needs when
permitting personally owned mobile devices to access enterprise resources.
Please review the second draft, which includes new updates to the
iOS BYOD implementation, and submit comments online on or before January 13th, 2023.
Visit the mobile device security page to submit your comments here.
We welcome your input and look forward to your comments. We invite
you to join our Community of Interest to receive news and updates about this
project by signing up on our website here.
– The Mobile Device Security Team
Vulnerabilities in network components, architecture files, and developer tools have become increasingly popular attack vectors to gain access into secure networks and devices. External tools and products that are managed by vendors and developers can pose a security risk, especially to targets in sensitive industries. Attacks on software and hardware supply chains, like Log4J and SolarWinds, have highlighted the importance of visibility across device components and proactively securing networks. A report published by Recorded Future in April 2022 detailed suspected electrical grid intrusion activity and implicated common IoT devices as the vector used to gain a foothold into operational technology (OT) networks and deploy malicious payloads. While investigating the attack activity, Microsoft researchers identified a vulnerable component on all the IP addresses published as IOCs and found evidence of a supply chain risk that may affect millions of organizations and devices.
We assessed the vulnerable component to be the Boa web server, which is often used to access settings and management consoles and sign-in screens in devices. Despite being discontinued in 2005, the Boa web server continues to be implemented by different vendors across a variety of IoT devices and popular software development kits (SDKs). Without developers managing the Boa web server, its known vulnerabilities could allow attackers to silently gain access to networks by collecting information from files. Moreover, those affected may be unaware that their devices run services using the discontinued Boa web server, and that firmware updates and downstream patches do not address its known vulnerabilities.
In this blog, we detail the risks affiliated with vulnerable components, highlighting the Boa web server, and how we suspect these components could be exploited to target critical industries. We also discuss the difficulties with identifying these components in device supply chains. To provide comprehensive protection against such attacks, we offer detection information to identify vulnerable components and guidance for organizations and network operators to improve their security posture.
The attack detailed in the Recorded Future report was one of several intrusion attempts on Indian critical infrastructure since 2020, with the most recent attack on IT assets confirmed in October 2022. Microsoft assesses that Boa servers were running on the IP addresses on the list of IOCs published by Recorded Future at the time of the report’s release and that the electrical grid attack targeted exposed IoT devices running Boa.
Microsoft further identified that half of the IP addresses published by Recorded Future returned suspicious HTTP response headers, which might be associated with the active deployment of the malicious tool identified by Recorded Future. The combination of Boa and suspicious response headers was identified on another set of IP addresses, displaying similar behavior to those found by Recorded Future. While these IP addresses are not confirmed as malicious, we recommend they be monitored to ensure no additional suspicious activity. Users of Microsoft Defender Threat Intelligence will find these IP addresses in the portal labeled as block-listed or suspicious:
Investigating the headers further indicated that over 10% of all active IP addresses returning the headers were related to critical industries, such as the petroleum industry and associated fleet services, with many of the IP addresses associated to IoT devices, such as routers, with unpatched critical vulnerabilities, highlighting an accessible attack vector for malware operators. Most of the suspicious HTTP response headers were returned over a short timeframe of several days, leading researchers to believe they may be associated with intrusion and malicious activity on networks.
Since the report’s publication, Microsoft researchers tracking the published IPs hosts have observed that all IP addresses have been compromised by a variety of attackers employing different malicious methods. For example, some of the IP addresses were further leveraged to download a variant of the Mirai malware family shortly following the report’s release. Microsoft also found evidence that across different devices on the IP addresses, there were attempts to connect with default credentials through brute force methods and attempts to run shell commands. Microsoft continues to see attackers attempting to exploit Boa vulnerabilities beyond the timeframe of the released report, indicating that it is still targeted as an attack vector.
The Boa web server is widely implemented across a variety of devices, including IoT devices ranging from routers to cameras, and is often used to access settings and management consoles as well as sign-in screens. The popularity of Boa web servers is especially concerning as Boa has been formally discontinued since 2005. Data from the Microsoft Defender Threat Intelligence platform identified over 1 million internet-exposed Boa server components around the world over the span of a week, as depicted in the below figure:
Boa web servers remain pervasive in the development of IoT devices, one reason for this could be its inclusion in popular SDKs, which contain essential functions that operate system on chip (SOC) implemented in microchips. Vulnerable components like Boa and SDKs are often distributed to customers within devices, contributing to supply chain vulnerabilities. Popular SDKs like those released by RealTek, are used in SOCs provided to companies that manufacture gateway devices like routers, access points, and repeaters. Critical vulnerabilities such as CVE-2021-35395, which affected the digital administration of devices using RealTek’s SDK, and CVE-2022-27255, a zero-click overflow vulnerability, reportedly affect millions of devices globally and allow attackers to launch code, compromise devices, deploy botnets, and move laterally on networks.
While patches for the RealTek SDK vulnerabilities are available, some vendors may not have included them in their device firmware updates, and the updates do not include patches for Boa vulnerabilities. Boa servers are affected by several known vulnerabilities, including arbitrary file access (CVE-2017-9833) and information disclosure (CVE-2021-33558). These vulnerabilities may allow attackers to execute code remotely after gaining device access by reading the “passwd” file from the device or accessing sensitive URIs in the web server to extract a user’s credentials. Moreover, these vulnerabilities require no authentication to exploit, making them attractive targets.
The popularity of the Boa web server displays the potential exposure risk of an insecure supply chain, even when security best practices are applied to devices in the network. Updating the firmware of IoT devices does not always patch SDKs or specific SOC components and there is limited visibility into components and whether they can be updated. The known CVEs impacting such components can allow an attacker to collect information about network assets before initiating attacks, and to gain access to a network undetected by obtaining valid credentials. In critical infrastructure networks, being able to collect information undetected prior to the attack allows the attackers to have much greater impact once the attack is initiated, potentially disrupting operations that can cost millions of dollars and affect millions of people.
As attackers seek new footholds into increasingly secure devices and networks, identifying and preventing distributed security risks through software and hardware supply chains, like outdated components, should be prioritized by organizations. This case displays the importance of proactive cyber security practices and the need to identify vulnerable components that may be leveraged by attackers.
Microsoft recommends that organizations and network operators follow best practice guidelines for their networks:
alert udp any any -> any any (msg:"Realtek eCOS SDK SIP Traffic Exploit CVE-2022-27255"; content: "invite"; depth: 6; nocase; content: "sip:"; content: "m=audio "; isdataat: 128,relative; content:!"|0d|"; within: 128;sid:20221031;)
|
|
|
|
|
|
|
The National Institute of Standards and Technology (NIST) has The finalized report, Digital Details, including a link to the final version of the report, Read More
|
NIST has published NIST Internal Report (IR) 8409, Measuring the
Common Vulnerability Scoring System Base Score Equation.
Calculating the severity of information technology vulnerabilities
is important for prioritizing vulnerability remediation and helping to
understand the risk of a vulnerability. The Common Vulnerability Scoring System
(CVSS) is a widely used approach for evaluating properties that lead to a
successful attack and the effects of a successful exploitation. This work
evaluates the validity of the CVSS version 3 base score equation in capturing
the expert opinion of its maintainers. Performing this analysis is necessary
because the equation design has been questioned since it has features that are
both unintuitive and unjustified by the CVSS specification. If one can show
that the equation reflects CVSS expert opinion, then that study justifies the
equation, and the security community can treat the equation as an opaque box
that functions as described.
This work shows that the CVSS base score equation closely —
though not perfectly — represents the CVSS maintainers’ expert opinion. These
findings validate that the CVSS base score equation represents the CVSS
maintainers’ domain knowledge to the extent described by these measurements.
STPPA: In the “Special Topics on Privacy and Public
Auditability” series, the NIST privacy-enhancing cryptography (PEC)
project hosts talks on various interconnected topics related to privacy and
public auditability. The goal is to convey basic technical background, incite
curiosity, suggest research questions and discuss applications, with an
emphasis on the role of cryptographic tools.
For more information, contact: [email protected]
As organizations increase their coverage of multifactor authentication (MFA), threat actors have begun to move to more sophisticated techniques to allow them to compromise corporate resources without needing to satisfy MFA. Recently, the Microsoft Detection and Response Team (DART) has seen an increase in attackers utilizing token theft for this purpose. By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. This poses to be a concerning tactic for defenders because the expertise needed to compromise a token is very low, is hard to detect, and few organizations have token theft mitigations in their incident response plan.
In the new world of hybrid work, users may be accessing corporate resources from personally owned or unmanaged devices which increases the risk of token theft occurring. These unmanaged devices likely have weaker security controls than those that are managed by organizations, and most importantly, are not visible to corporate IT. Users on these devices may be signed into both personal websites and corporate applications at the same time, allowing attackers to compromise tokens belonging to both.
As far as mitigations go, publicly available open-source tools for exploiting token theft already exist, and commodity credential theft malware has already been adapted to include this technique in their arsenal. Detecting token theft can be difficult without the proper safeguards and visibility into authentication endpoints. Microsoft DART aims to provide defenders with the knowledge and strategies necessary to mitigate this tactic until permanent solutions become available.
Tokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a resource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that token, the user must sign into Azure AD using their credentials. At that point, depending on policy, they may be required to complete MFA. The user then presents that token to the web application, which validates the token and allows the user access.
When Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA, and more. It also includes any privilege a user has in Azure AD. If you sign in as a Global Administrator to your Azure AD tenant, then the token will reflect that. Two of the most common token theft techniques DART has observed have been through adversary-in-the-middle (AitM) frameworks or the utilization of commodity malware (which enables a ‘pass-the-cookie’ scenario).
With traditional credential phishing, the attacker may use the credentials they have compromised to try and sign in to Azure AD. If the security policy requires MFA, the attacker is halted from being able to successfully sign in. Though the users’ credentials were compromised in this attack, the threat actor is prevented from accessing organizational resources.
Attacker methodologies are always evolving, and to that end DART has seen an increase in attackers using AitM techniques to steal tokens instead of passwords. Frameworks like Evilginx2 go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token.
If a regular user is phished and their token stolen, the attacker may attempt business email compromise (BEC) for financial gain. If a token with Global Administrator privilege is stolen, then they may attempt to take over the Azure AD tenant entirely, resulting in loss of administrative control and total tenant compromise.
A “pass-the-cookie” attack is a type of attack where an attacker can bypass authentication controls by compromising browser cookies. At a high level, browser cookies allow web applications to store user authentication information. This allows a website to keep you signed in and not constantly prompt for credentials every time you click a new page.
“Pass-the-cookie” is like pass-the-hash or pass-the-ticket attacks in Active Directory. After authentication to Azure AD via a browser, a cookie is created and stored for that session. If an attacker can compromise a device and extract the browser cookies, they could pass that cookie into a separate web browser on another system, bypassing security checkpoints along the way. Users who are accessing corporate resources on personal devices are especially at risk. Personal devices often have weaker security controls than corporate-managed devices and IT staff lack visibility to those devices to determine compromise. They also have additional attack vectors, such as personal email addresses or social media accounts users may access on the same device. Attackers can compromise these systems and steal the authentication cookies associated with both personal accounts and the users’ corporate credentials.
Commodity credential theft malware like Emotet, Redline, IcedID, and more all have built-in functionality to extract and exfiltrate browser cookies. Additionally, the attacker does not have to know the compromised account password or even the email address for this to work—
Organizations can take a significant step toward reducing the risk of token theft by ensuring that they have full visibility of where and how their users are authenticating. To access critical applications like Exchange Online or SharePoint, the device used should be known by the organization. Utilizing compliance tools like Intune in combination with device based conditional access policies can help to keep devices up to date with patches, antivirus definitions, and EDR solutions. Allowing only known devices that adhere to Microsoft’s recommended security baselines helps mitigate the risk of commodity credential theft malware being able to compromise end user devices.
For those devices that remain unmanaged, consider utilizing session conditional access policies and other compensating controls to reduce the impact of token theft:
Protect your users by blocking initial access:
We recognize that while it may be recommended for organizations to enforce location, device compliance, and session lifetime controls to all applications it may not always be practical. Decisionmakers should instead focus on deploying these controls to applications and users that have the greatest risk to the organization which may include:
When a token is replayed, the sign-in from the threat actor can flag anomalous features and impossible travel alerts. Azure Active Directory Identity Protection and Microsoft Defender for Cloud Apps both alert on these events. Azure AD Identity Protection has a specific detection for anomalous token events. The token anomaly detection in Azure AD Identity Protection is tuned to incur more noise than other alerts. This helps ensure that genuine token theft events aren’t missed.
DART recommends focusing on high severity alerts and focusing on those users who trigger multiple alerts rapidly. Detection rules that map to the MITRE ATT&CK framework can help detect genuine compromise. For example, a risky sign-in followed closely by indicators of persistence techniques, such as mailbox rule creation.
If a user is confirmed compromised and their token stolen, there are several steps DART recommends evicting the threat actor. Azure AD provides the capability to revoke a refresh token. Once a refresh token is revoked, it’s no longer valid. When the associated access token expires, the user will be prompted to re-authenticate. The following graphic outlines the methods by which access is terminated entirely:
It’s crucial to use both the Azure AD portal, Microsoft Graph, or Azure AD PowerShell in addition to resetting the users’ passwords to complete the revocation process.
Importantly, revoking refresh tokens via the above methods doesn’t invalidate the access token immediately, which can still be valid for up to an hour. This means the threat actor may still have access to a compromised user’s account until the access token expires. Azure AD now supports continuous access evaluation for Exchange, SharePoint and Teams, allowing access tokens to be revoked in near real time following a ‘critical event’. This helps to significantly reduce the up to one hour delay between refresh token revocation and access token expiry.
Microsoft DART also recommends checking the compromised user’s account for other signs of persistence. These can include:
To strengthen your security posture, you should configure alerts to review high-risk modifications to a tenant. Some examples of this are:
Incident responders should review any audit logs related to user activity to look for signs of persistence. Logs available in the Unified Audit Log, Microsoft Defender for Cloud Apps, or SIEM solutions like Microsoft Sentinel can aid with investigations.
Although tactics from threat actors are constantly evolving, it is important to note that multifactor authentication, when combined with other basic security hygiene—
Fundamentally, it is important to consider the identity trust chain for the organization, spanning both internally and externally. The trust chain includes all systems (such as identity providers, federated identity providers, MFA services, VPN solutions, cloud-service providers, and enterprise applications) that issue access tokens and grant privilege for identities both cloud and on-premises, resulting in implicit trust between them.
In instances of token theft, adversaries insert themselves in the middle of the trust chain and often subsequently circumvent security controls. Having visibility, alerting, insights, and a full understanding of where security controls are enforced is key. Treating both identity providers that generate access tokens and their associated privileged identities as critical assets is strongly encouraged.
Adversaries have and will continue to find ways to evade security controls. The tactics utilized by threat actors to bypass controls and compromise tokens present additional challenges to defenders. However, by implementing the controls presented in this blog DART believes that organizations will be better prepared to detect, mitigate, and respond to threats of this nature moving forward.
NIST has published Special Publication (SP) 800-215, Guide to a Secure
Enterprise Network Landscape.
Access to multiple cloud services (e.g., IaaS, SaaS), the
geographic spread of enterprise Information Technology (IT) resources
(including multiple data centers and multiple branch offices), and the
emergence of highly distributed loosely coupled microservices-based
applications (as opposed to monolithic ones) have significantly altered the
enterprise network landscape. This transformation has the following security
impacts: (a) disappearance of the concept of a perimeter associated with the
enterprise network, (b) an increase in attack surfaces due to the sheer
multiplicity of IT resource components (e.g., computing, networking, and
storage), and (c) the ability of attackers to escalate sophisticated attacks
across several network boundaries by leveraging extensive connectivity features
within and across the individual network segments.
NIST SP 800-215 provides guidance from a secure operations
perspective. It examines the security limitations of current network access
solutions (e.g., VPNs) to the enterprise network as well as point security
solutions with traditional network appliances with enhanced features (e.g.,
firewalls, CASB for cloud access), including the usage of network visibility,
monitoring, and provisioning tools. This document also discusses emerging
network configurations that each address a specific security function (e.g.,
application/services security, cloud services access security, device or
endpoint security) and security frameworks, such as zero trust network access
(ZTNA), microsegmentation, and SDP that combine these individual
configurations. Additionally, the document highlights cloud-based WAN
infrastructures, such as SASE with widespread point of presence (PoP), that
combine use of the latest WAN technologies (e.g., SD-WAN) with a comprehensive
set of security services.
Business impact analyses (BIAs) have been traditionally used for
business continuity and disaster recovery (BC/DR) planning to understand the
potential impacts of outages that compromise IT infrastructure. However, BIA
analyses can be easily expanded to consider outages related to cyber risks and
issues attributable to confidentiality and integrity.
NIST Interagency Report (IR) 8286D, Using Business
Impact Analysis to Inform Risk Prioritization and Response,
goes beyond availability to also include confidentiality and integrity impact
analyses. This fifth publication in the NIST IR 8286 document series, Integrating Cybersecurity and
Enterprise Risk Management, discusses the identification and
management of risk as it propagates from system to organization and from
organization to enterprise, which in turn better informs Enterprise Risk
Management deliberations. NIST IR 8286D expands typical BIA discussions to
inform risk prioritization and response by quantifying the organizational
impact and enterprise consequences of compromised IT Assets.
NIST IR 8286D pairs with several other reports:
The NIST IR 8286 series enables risk practitioners to integrate
CSRM activities more fully into the broader enterprise risk processes. Because
information and technology comprise some of the enterprise’s most valuable
resources, it is vital that directors and senior leaders have a clear understanding
of cybersecurity risk posture at all times. It is similarly vital that those
identifying, assessing, and treating cybersecurity risk understand enterprise
strategic objectives when making risk decisions.
The authors of the NIST IR 8286 series hope that these
publications will spark further industry discussion. As NIST continues to
develop frameworks and guidance to support the application and integration of
information and technology, many of the series’ concepts will be considered for
inclusion.