Don’t Mess With Texas Privacy: “We will hold all these companies accountable,” rants state attorney general Ken Paxton (pictured).
The post Allstate Violates Drivers’ Privacy, Texas AG Alleges appeared first on Security Boulevard.
Several people have recently produced high-quality work around Intune tradecraft. I want to specifically mention:
Intune is a Microsoft service that administrators can use for endpoint management. Microsoft appears to be investing most of its efforts into pushing administrators towards Intune and away from other endpoint management systems such as SCCM.
Intune isn’t universal… yet.Intune adoption appears to be far from universal — admins are still widely using “legacy” endpoint management systems such as Group Policy and SCCM; however, with Microsoft pushing its customers towards Intune, we expect Intune adoption to accelerate in the coming years and for Intune tradecraft to become more relevant.
Intune is an attractive system for adversaries to target, as it is an authorized system capable of performing the most highly privileged actions on endpoints, such as running arbitrary commands and applications as the NT AUTHORITY\SYSTEM principal.
Intune Trust BoundaryIntune is an Azure service and requires an existing Entra tenant for admins to use it. Only one Intune instance can be associated with each Entra tenant. Intune instances can not be associated with more than one Entra tenant.
Two roles in the Entra tenant grant full control of an Intune instance:
There is also a distinct authorization system within the Intune service with its own roles and mechanics.
Because the Intune service must be associated with precisely one Entra tenant, and because Entra’s authorization system grants full control of the Intune instance, the trust boundary around an Intune instance is established and enforced by the Entra tenant:
Intune Devices vs. Entra DevicesThe Intune service refers to managed endpoints as “devices.” This is the same word Entra uses when describing endpoints. Intune Devices are typically endpoints that are registered or joined to the Entra tenant, but this is not a hard requirement. It is possible to manage an endpoint in Intune while that endpoint is not registered or joined to an Entra tenant.
Because of this, Intune Devices are distinct objects from Entra Devices. They are accessed and managed with a distinct API and they have universally unique identifiers that are distinct from Entra Devices:
We can determine when an Intune Device is the same endpoint as an Entra Device by comparing two fields:
In this example, we can see that the two devices are, in fact, the same endpoint:
An Intune Device may represent the same endpoint as an Entra Device; furthermore, both of these objects may also represent an on-premises Active Directory joined computer. When that is the case, the on-premises AD computer’s LDAP object will have the same value for its objectGUID property:
This is one endpoint represented across three systems with three distinct objects.
Intune RBAC vs. Entra RBAC vs. MS GraphIntune has its own role-based access control (RBAC) system that is distinct from the Entra ID RBAC system, but the Intune service is also subject to Entra RBAC — an Entra Global Admin has full control of the Intune instance. Intune is accessed via the MS Graph API and there are several relevant MS Graph permissions that can control access to the Intune instance as well.
Intune RBAC — Role AssignmentsThe Intune RBAC system is very similar to the Entra RBAC system in that it is based on role definitions, role assignments, permissions, and scopes.
The first material difference of note is that Intune roles must be assigned to groups. While it is possible to create an Intune role assignment for a user, the system will not respect this configuration. Intune role assignments only work when assigned to groups, while Entra roles work when assigned to any principal type:
Intune RBAC — PermissionsIntune permissions (more accurately called Resource Operations) enable specific actions against specific Intune object classes. Intune permissions are formatted as:
Microsoft.<ServiceName>_<ObjectClass>_<Action>All Intune permissions have “Intune” as the service name.
An example Intune permission is:
Microsoft.Intune_DeviceConfigurations_CreateThis permission enables a principal to Create new Intune objects called DeviceConfigurations. This is a powerful permission that enables remote code execution on Intune-managed endpoints.
At time of writing, Intune has 239 distinct permissions, there does not appear to be an online resource listing all of these permissions, and MS Graph serves them at the /deviceManagement/resourceOperations API endpoint. BARK’s Get-IntuneResourceOperations hits that endpoint to list all Intune permissions.
Intune RBAC — Scope GroupsIntune’s RBAC system supports limiting role assignments to particular sets of endpoints. The mechanism for this is called Scope Groups. Scope Groups are Entra ID security groups. The default (and most common) configuration is to use a virtual scope group called allDevicesAndLicensedUsers. This scope group value means the role assignment will enable the principal to perform actions against all devices in the Intune instance.
Scope Groups may be used to limit which devices a principal can control when granted a role assignment. For example, the Entra group called “Seattle Admins” may have an Intune role assignment for the built-in role called “School Administrator”:
If the Intune admin wants to limit this role assignment to only granting control of devices in Seattle, they may create a new Entra group called “Seattle Devices” and then add the relevant Entra Devices (not the Intune Devices) to that group.
Recall from earlier that Entra devices and Intune devices that represent the same endpoint share a common property value that ties the objects to the same host.
Putting this all together, we can visualize the above configuration as such:
The one piece that is missing is the inclusion of the Scope Group configuration within the role assignment itself. Let’s add that in:
This configuration means that the “Seattle Admins” group will have all permissions granted by the “School Administrator” role, but only for those devices that belong to the groups listed in the “scopeGroups” attribute of the role assignment. The “Seattle Admins” group gains control of the Intune Device due to this configuration:
There may be other Intune devices in this instance, but if those devices are not added to the “Seattle Devices” group, then this configuration means the “Seattle Admins” group does not gain control of those other devices:
If an Entra Device that is associated with an Intune Device is added to the “Seattle Devices” group, then the “School Admins” group will gain control of that device:
If the “scopeGroups” property on the role assignment is changed to allDevicesAndLicensedUsers, then the “Seattle Admins” group will gain control of all Intune-managed devices within the Intune instance:
Intune RBAC — Scope TagsThe Microsoft documentation about scope tags begins with this paragraph:
You can use RBAC and scope tags to make sure that the right admins have the correct access and visibility to the required Intune objects. Roles determine what access admins have to which objects. Scope tags determine which objects admins can see.
Scope Tags limit visibility, they do not limit access.
Scope Tags are a distinct class of Intune object. They are referenced on most Intune objects including roles, role assignments, applications, and devices. For example, let’s say we want members of the “Seattle Admins” group to only be able to see devices that belong to the “Seattle Devices” group.
The Intune admin must first create the scope tag. Then, they modify the scope tag so that the scope tag itself includes the “Seattle Devices” group:
Next, the Intune admin would modify the existing role assignment connecting the “Seattle Admins” group to the “School Administrator” role. The modification is to update the “scopeTags” attribute on the role assignment itself to reference the existing scope tag. When this update happens, the members of the “Seattle Admins” group will lose the ability to see any device that is not a member of the “Seattle Devices” group:
While the members of the “Seattle Admins” group can no longer see those devices in Intune, they still control those devices. We can prove this in a lab by logging in as a member of the “Seattle Admins” group and deploying a new configuration to include all devices. Because the “scopeGroups” attribute of the role assignment is inclusive of all devices, the change will apply to all devices.
Scope tags do not appear to be commonly used in the real world. There are complicated rules around scope tags that I believe will introduce enough friction to discourage most Intune admins from making use of scope tags.
Entra ID RBACTwo built-in roles in Entra have full control of an Intune instance:
Principals with either of those roles are not limited in any way by Intune RBAC. I still need to look into which specific Entra ID permissions may be relevant in the same way, as admins may be using custom Entra ID roles that also have control of Intune.
MS Graph App RolesIntune is accessed via MS Graph, which has its own set of permissions related to Intune. The MS Graph app roles that apply to Intune include, for example:
Most (all?) of the Intune-relevant MS Graph app roles begin with “DeviceManagement”.
Some of these app roles enable abuse. For example:
Those are the two MS Graph app roles I have completed the research on. There are others that appear very attractive, including:
Intune is an endpoint management system and, as such, provides Intune admins with various mechanisms for performing privileged actions on endpoints such as controlling operating system configurations, installing arbitrary applications, and running arbitrary commands.
One method of running arbitrary commands is by using Remediations (previously known as “Proactive Remediations”). Remediations allow Intune admins to run PowerShell scripts on Intune-managed devices as the Windows NT AUTHORITY\SYSTEM principal.
Remediations run PowerShell scripts. To run a remediation script, the admin must create or modify an existing PowerShell script. This step is done locally on the admin’s own host.
Next, the Intune admin must create or modify an existing script package. Creating a new script package is done by making a “POST” request to the MS Graph /devicemanagement/deviceHealthScripts endpoint. This is a privileged action. In order to successfully make a “POST” request to that endpoint, a principal must have one of the following:
A. One of these Entra ID roles:
B. An Intune role assignment including the atomic permission (resource operation), Microsoft.Intune_DeviceConfigurations_Create. These built-in Intune roles have that permission:
C. The MS Graph app role, DeviceManagementConfiguration.ReadWrite.All
The PowerShell script is stored as a base64-encoded string on the deviceHealthScript resource:
The script package defines which groups are able to run the package. For example, the admin may assign the script package to the “Seattle Devices” group in order to make the package available to those devices:
Script packages also allow admins to include or exclude devices using assignment filters:
Finally, script packages allow admins to exclude groups using an exclusion property of the package:
We have not observed wide-spread usage of exclusion groups or inclusion/exclusion filters. Due to the complexity involved with these filters, we do not expect most Intune admins to make use of filters beyond using the readily-available “All devices” assignment, or selecting specific groups to include.
We expect a typical environment to not make use of most of these filter mechanisms. In our example, we will simplify the diagram so that the “Seattle Devices” group is included in the script package:
Now that the script package is created and assigned to the “Seattle Devices” group, the script will automatically run on a specified interval; the default is once every 24 hours.
Intune Arbitrary Command Execution via On-Demand Proactive RemediationIntune allows administrators to run specific remediation scripts on specific devices via a feature called on-demand proactive remediations. This feature is currently in preview and subject to change.
In order to run an on-demand proactive remediation, the admin must create a script (or target an existing script). The documentation for the initiateOnDemandProactiveRemediation action indicates that this action can be used to trigger several kinds of scripts within the Intune platform:
At the time of writing (December 17, 2024), I have finished the work to understand which permissions are required in order to perform the initiateOnDemandProactiveRemediation action when sending a POST request to this URI:
A service principal with the following MS Graph app role will successfully perform a “POST” request to the above endpoint:
A principal with an Intune role activated that includes one of the following permissions will successfully perform a “POST” request to the above endpoint:
The following built-in Intune roles have that/those permissions:
In the previous section titled “Intune Arbitrary Command Execution via Remediations”, we discussed how script package filters limit which devices a remediation script package will automatically run on. For the endpoint discussed in this section, the initiateOnDemandProactiveRemediation action is not limited by those filters. Even if a script package is explicitly configured to not run on a set of devices, the initiateOnDemandProactiveRemediation action will successfully execute those same script packages on that same set of devices.
This may or may not be Microsoft’s intent. I opened a GitHub issue here asking them whether this is intended: https://github.com/MSEndpointMgr/Intune/issues/76
Intune Script PackagesThere are several Intune resource types admins can use to store and execute scripts on Intune-managed devices. The most obvious is a resource called deviceHealthScript. These objects are called “Script Packages” in the Intune portal GUI:
Look carefully at the above screenshot. Look at what the arrow on the left is pointing at. The Intune portal GUI calls the items in this list “Script Packages”. The Intune GUI says there are 37 “script packages”. Now carefully look at what the arrow on the right is pointing at: the number 37. Now look at the URI that was accessed to retrieve that number: it’s the deviceHealthScripts URI.
“Script Package” is the customer-facing name. That is the name Microsoft uses in the remediations feature documentation. “deviceHealthScript” is the name that MS Graph’s Intune API endpoints uses.
Because most Intune admins will likely be more familiar with the term “Script Package”, that is the name we will use when describing these objects.
Script packages (deviceHealthScripts) are Intune resources. There are several properties on these objects that are interesting to an attacker:
Intune admins can populate the detectionScriptContent and remediationScriptContent properties of these objects with anything they want; it doesn’t need to be a PowerShell script, but PowerShell is the only type of script that will successfully execute on an endpoint running a script package.
Adversaries find PowerShell scripts attractive because they may have contents that lead to successfully actioning an operational objective. Those contents may include less-sensitive data such as internal hostnames, or highly-sensitive data such as credentials.
A principal with one of the following Entra ID admin roles can read the contents of all script packages within an Intune instance:
A principal with one of the following built-in Intune roles can read the contents of all script packages within an Intune instance:
The atomic Intune permission that enables reading script package contents is:
These MS Graph app roles allow a service principal to read all deviceHealthScripts in the Intune instance:
Platform scripts are Intune resources that store information about scripts that can run on Intune-managed devices. “Platform script” is the user-facing name of this resource. The MS Graph API refers to these resources as deviceManagementScripts. We will refer to them as “Platform Scripts”.
Platform scripts, similar to script packages, contain the base64-encoded script that will run on Intune-managed endpoints. Those scripts may contain sensitive information such as internal host names or credentials.
A principal with one of the following Entra ID admin roles can read the contents of all platform scripts within an Intune instance:
A principal with one of the following Intune roles can read the contents of all platform scripts within an Intune instance:
The atomic Intune permission that enables reading platform script contents is:
These MS Graph app roles allow a service principal to read all platform scripts in the Intune instance:
Compliance scripts are scripts that run during an Intune-managed Windows or Linux system. Compliance scripts are referred to as “Scripts” within the compliance policy GUI, and as “deviceComplianceScripts” by the API. We will call them “Compliance Scripts”.
Compliance scripts are associated with compliance policies. Compliance policies specify which devices/groups are in-scope for that particular policy. Compliance scripts automatically run once every 24 hours when associated with a compliance policy.
Admins can force a compliance script to execute “on-demand” by instructing a device to “sync”.
Intune Device User HuntingWhen an on-premises Active Directory user logs onto a domain-joined computer, several artifacts are created within the operating system that make it possible to impersonate that user. This is well-established knowledge going back to at least 2008 when Luke Jennings published the seminal paper, “Security Implications of Windows Access Tokens — A Penetration Tester’s Guide”.
Similar tradecraft exists to take advantage of Entra users logging on to Windows endpoints, as discussed by Dirk-jan Mollema in, for example, his blog post titled “Digging Further Into the Primary Refresh Token”, and as discussed by Adam Chester in his blog post titled, “WAM BAM — Recovering Web Tokens From Office”.
This tradecraft means adversaries are interested in discovering which Intune-managed devices users have logged onto. There are several data sources we can pull from to discover which users have logged onto which devices, each with their own strengths and drawbacks:
User Hunting via Sign-in LogsOf the built-in options, Entra sign-in logs are the highest-fidelity source for discovering which users have performed some kind of abusable logon on a device.
Sign-in logs are a trove of information. In the above screenshot, we can see:
This is more than enough information to populate an attack graph:
Notice that, in the above diagram, we have labeled the device as an “Entra Device” and not as an “Intune Device”. This is because Entra logs the Entra device identifier, NOT the Intune device identifier. Recall from earlier that we can identify hosts that are both Entra-joined and Intune-managed devices by comparing the deviceId and azureADDeviceId property values:
We can connect the Entra and Intune device nodes with an edge indicating they are the same host. This reveals the full pattern connecting the Intune device to the Entra user:
But Entra sign-in logs come with serious limitations. Adversaries may be unable or unwilling to rely on Entra sign-in logs for user hunting for a few reasons:
Intune devices have a property called usersLoggedOn. This attribute is a collection of loggedOnUser resources. A loggedOnUser resource contains two pieces of information:
This data source gives us all three elements we need to construct a similar attack graph as in the previous section:
Using this attribute for user hunting comes with some advantages:
Entra and Intune devices have “owners”. Ownership of an Entra or Intune device does not guarantee control of the device, nor does it guarantee that the user that owns the device uses the device. In the real world, we see many Entra and Intune devices where the owner has been set to an IT contact. We do not consider device ownership a reliable indicator for the purposes of user hunting.
User Hunting via Intune Device Primary UserIntune devices have “primary users”. The “primary user” value of an Intune device is set different ways depending on how the device was enrolled: https://learn.microsoft.com/en-us/mem/intune/remote-actions/find-primary-user?WT.mc_id=Portal-Microsoft_Intune_Devices#who-is-assigned-as-the-primary-user
In the real world, we have seen little reason to put much trust in the “primary user” of an Intune device for user hunting purposes, especially in light of the Intune device usersLoggedOn attribute.
Conclusion and Future WorkIntune attack paths are interesting for the attack paths that emerge within the Intune platform itself. But these attack paths are compelling for the attack paths that emerge connecting Entra/Azure to on-premises Active Directory and vice versa. This blog post hopefully sets some foundational knowledge to setup for the next post(s) in this series, which will show real examples of performing the abuse primitives this post discusses.
I will also be continuing Intune tradecraft research, to include:
Intune Attack Paths — Part 1 was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post Intune Attack Paths — Part 1 appeared first on Security Boulevard.
Deb Radcliff interviews OWASP Top Ten core team member Brian Glas. What do the OWASP Top Ten web application vulnerabilities have to do with C languages? And where do those vulnerabilities coincide with Software Bills of Materials (SBOMs)? As the Top Ten core team begins analyzing the 2025 data, we pose these questions to Brian…
The post OWASP Top 10: What’s C Got to Do With It? appeared first on CodeSecure.
The post OWASP Top 10: What’s C Got to Do With It? appeared first on Security Boulevard.
Building an in-house redaction system requires overcoming significant technical challenges and investing considerable resources to develop and maintain the process. This article explores some of the challenges you may face if your organization decides to go down the build-it-yourself path.
The post Redacting sensitive free-text data: build vs buy appeared first on Security Boulevard.
Silver Spring, United States / Maryland, 15th January 2025, CyberNewsWire
The post Aembit Announces Speaker Lineup for the Inaugural NHIcon appeared first on Security Boulevard.
Tel Aviv, Israel, 15th January 2025, CyberNewsWire
The post Sweet Security Introduces Patent-Pending LLM-Powered Detection Engine, Reducing Cloud Detection Noise to 0.04% appeared first on Security Boulevard.
Sweet Security today added a cloud detection engine to its cybersecurity portfolio that makes use of a large language model (LLM) to identify potential threats in real-time.
The post Sweet Security Leverages LLM to Improve Cloud Security appeared first on Security Boulevard.
Zero trust as a concept is simple to grasp. Implementing a zero trust architecture, on the other hand, is complex because it involves addressing a unique mix of process, procedure, technology and user education. Here are some considerations to keep in mind as you begin your journey.
Draft guidance on implementing a zero trust architecture, released by the National Institute of Standards and Technology (NIST) on Dec. 4, 2024, gives government agencies and private sector organizations a solid blueprint to follow. There are a number of additional considerations to keep in mind as you begin your journey.
First and foremost, zero trust is an alternative way of thinking about information security that treats trust as a vulnerability. It removes trust entirely from digital systems and is built upon the idea that security must become ubiquitous throughout the infrastructure. The concepts of zero trust are simple:
A zero trust architecture can be implemented using commercial off-the-shelf technology. It's built upon current cybersecurity best practices and dovetails with a robust exposure management program. In fact, exposure management and zero trust go hand-in-hand.
5 things to keep in mind about zero trustHere are five considerations as you begin your zero trust journey:
Zero trust as a concept is simple to grasp. What makes zero trust complex to implement are the same factors that make any cybersecurity strategy complex: the unique mix of processes, procedures and technology found in your IT infrastructure, as well as the need for significant user education. It's best to start small and roll out from there, rather than trying to boil the ocean.
For cybersecurity leaders in government agencies, preparing for a zero trust architecture is less an exercise in evaluating technologies and more an exercise in strategic thinking, requiring you to answer fundamental questions such as:
Answering these questions requires full visibility and continuous monitoring of your entire attack surface, including IT, internet of things (IoT) and operational technology (OT) assets, and the ability to assess the criticality of each asset to deliver on your organization's core mission. No zero trust journey can begin without first addressing these fundamentals of exposure management.
How zero trust and exposure management go hand-in-handExposure management transcends the limitations of siloed security programs. Built on the foundations of risk-based vulnerability management, exposure management takes a broader view across your modern attack surface, applying both technical and business context to more precisely identify and more accurately communicate cyber risk, enabling better business outcomes.
An exposure management program combines technologies such as vulnerability management, web application security, cloud security, identity security, attack path analysis and patch management to help an organization understand the full breadth and depth of its exposures and take the actions needed to reduce them through remediation and incident response workflows. Exposure management gives security teams a full, dynamic and accurate picture of the attack surface at any point in time, aiding in the implementation of zero trust policies and architecture.
Learn moreThe post 5 Things Government Agencies Need to Know About Zero Trust appeared first on Security Boulevard.
Discover how Grip complements TPRM platforms by uncovering shadow SaaS, enhancing identity security, and addressing risks traditional TPRM methods miss.
The post Grip vs. TPRM | Amplify your TPRM Strategy appeared first on Security Boulevard.
The rapid increase in cyberattacks is putting greater pressure on Cyber Resilience and IT Infrastructure teams to ensure the reliability, integrity, and availability of their systems
The post The CISOs Guide to Cyber Recovery appeared first on Continuity™.
The post The CISOs Guide to Cyber Recovery appeared first on Security Boulevard.
Prague, Czech republic, 15th January 2025, CyberNewsWire
The post Wultra Secures €3M to Protect Financial Institutions from Quantum Threats appeared first on Security Boulevard.
As 2024 drew to a close, Google caught global attention with the announcement of its latest quantum computing chip, Willow. Many believe that with Willow, Google has set a new benchmark for 2025, unveiling the extraordinary potential of quantum computing and what the quantum future could look like in the days ahead. If you think […]
The post Google’s Willow Chip: Another Push to Start Your Post-Quantum Cryptography (PQC) Preparation Now appeared first on Security Boulevard.
The cybersecurity landscape is entering an unprecedented era of complexity, with AI-driven threats, geopolitical tensions, and supply chain vulnerabilities reshaping how organizations approach digital security. This analysis explores key trends and strategic imperatives for 2025 and beyond.
The post The Future of Cybersecurity: Global Outlook 2025 and Beyond appeared first on Security Boulevard.
The post Patch Tuesday Update - January 2024 appeared first on Digital Defense.
The post Patch Tuesday Update – January 2024 appeared first on Security Boulevard.
Attacks on individual applications were down month to month in December 2024, but one of the most dangerous types of attacks was up significantly. That’s according to data Contrast Security publishes monthly about the detection and response of real-world application and application programming interface (API) attacks with Application Detection and Response (ADR). What you’re about to see is data that we gather from the attacks on our apps and those of our customers, anonymized and averaged.
The post Unsafe Deserialization Attacks Surge | December Attack Data | Contrast Security appeared first on Security Boulevard.
Find out why unknown build assets is a growing problem and how Legit can help.
The post How to Prevent Risk From Unknown Build Assets appeared first on Security Boulevard.
Fortinet patched a zero day authentication bypass vulnerability in FortiOS and FortiProxy that has been actively exploited in the wild as a zero-day since November 2024.
BackgroundOn January 14, Fortinet released a security advisory (FG-IR-24-535) addressing a critical severity vulnerability impacting FortiOS and FortiProxy.
CVE Description CVSSv3 CVE-2024-55591 FortiOS and FortiProxy Authentication Bypass Vulnerability 9.6 AnalysisCVE-2024-55591 is an authentication bypass vulnerability in FortiOS and FortiProxy. An unauthenticated, remote attacker could exploit this vulnerability by sending a specially crafted request to a Node.js websocket module. Successful exploitation may grant an attacker super-admin privileges on a vulnerable device. According to the Fortinet advisory, this vulnerability has been exploited in the wild.
Zero Day Campaign May Have Been Active Since November
Researchers at Arctic Wolf published a blog post on January 10 detailing a campaign first observed in mid-November 2024 of suspicious activity related to the exploitation of a zero-day vulnerability, which is presumed to be CVE-2024-55591. Arctic Wolf Labs details four distinct phases of the campaign that were observed against Fortinet FortiGate firewall devices; scanning, reconnaissance, SSL VPN configuration and lateral movement. For more information on the observations of this campaign, we recommend reviewing its blog post.
At the time this blog was published, the Fortinet advisory did not credit Arctic Wolf with the discovery of CVE-2024-55591. However, the indicators of compromise (IoCs) listed in the Fortinet advisory overlap with the report from Arctic Wolf.
Historical exploitation of Fortinet FortiOS and FortiProxy
Fortinet FortiOS and FortiProxy have been targeted by threat actors previously, including targeting by advanced persistent threat (APT) actors. We’ve written about several noteworthy Fortinet flaws since 2019, including flaws impacting SSL VPNs from Fortinet and other vendors:
CVE Description Patched Tenable Blog CVE-2024-21762 Fortinet FortiOS Out-of-bound Write Vulnerability in sslvpnd February 2024 CVE-2024-21762: Critical Fortinet FortiOS Out-of-Bound Write SSL VPN Vulnerability CVE-2023-27997 FortiOS and FortiProxy Heap-Based Buffer Overflow Vulnerability June 2023 CVE-2023-27997: Heap-Based Buffer Overflow in Fortinet FortiOS and FortiProxy SSL-VPN (XORtigate) CVE-2022-42475 FortiOS and FortiProxy Heap-Based Buffer Overflow Vulnerability December 2022CVE-2022-42475: Fortinet Patches Zero Day in FortiOS SSL VPNs
AA23-250A: Multiple Nation-State Threat Actors Exploit CVE-2022-47966 and CVE-2022-42475
CVE-2022-40684 FortiOS and FortiProxy Authentication Bypass Vulnerability October 2022 CVE-2022-40684: Critical Authentication Bypass in FortiOS and FortiProxy CVE-2020-12812 FortiOS Improper Authentication Vulnerability July 2020 CVE-2018-13379, CVE-2019-5591, CVE-2020-12812: Fortinet Vulnerabilities Targeted by APT Actors CVE-2019-5591 FortiOS Default Configuration Vulnerability July 2019 CVE-2018-13379, CVE-2019-5591, CVE-2020-12812: Fortinet Vulnerabilities Targeted by APT Actors CVE-2018-13379 FortiOS Path Traversal/Arbitrary File Read Vulnerability August 2019 CVE-2018-13379, CVE-2019-11510: FortiGate and Pulse Connect Secure Vulnerabilities Exploited In the Wild Proof of conceptAt the time this blog post was published, there were no public proof-of-concept exploits for CVE-2024-55591.
SolutionFortinet published its security advisory (FG-IR-24-535) on January 14 to address this vulnerability. The advisory also contains IoCs and workaround steps that can be utilized if immediate patching is not feasible. Fortinet has released the following patches for FortiOS and FortiProxy.
Affected Product Affected Version Fixed Version FortiOS 7.0 7.0.0 through 7.0.16 Upgrade to 7.0.17 or above FortiProxy 7.0 7.0.0 through 7.0.19 Upgrade to 7.0.20 or above FortiProxy 7.2 7.2.0 through 7.2.12 Upgrade to 7.2.13 or aboveFortinet also released several additional security advisories on January 14 for vulnerabilities affecting FortiOS and FortiProxy:
Affected Product(s) Vulnerability Description Security Advisory CVSSv3/Severity FortiOS, FortiProxy, FortiMail, FortiSwitch, FortiVoiceEnterprise, FortiNDR, FortiWLC, FortiADC, FortiAuthenticator, FortiRecorder, FortiDDoS-F, FortiDDoS, FortiSOAR and FortiTester An externally controlled reference to a resource may allow an unauthenticated attacker to poison web caches between an affected device and an attacker using crafted HTTP requests FG-IR-23-494 4.1 / Medium FortiAnalyzer, FortiAnalyzer Cloud, FortiAuthenticator, FortiManager, FortiManager Cloud, FortiOS, FortiProxy, FortiSASE An unauthenticated attacker with access to the Security Fabric protocol may be able to brute force an affected product to bypass authentication. FG-IR-24-221 8.0 / High FortiOS An authenticated, remote attacker may be able to prevent access to the GUI using specially crafted requests and causing a denial of service (DoS) condition. FG-IR-24-250 4.8 / Medium FortiOS An authenticated attacker may be able to cause a DoS condition due to a NULL pointer dereference vulnerability in the SSLVPN web portal. FG-IR-23-473 6.2 / Medium FortiManager, FortiOS, FortiProxy, FortiRecorder, FortiSASE, FortiVoice and FortiWeb A path traversal vulnerability may be exploited by a remote attacker with access to the security fabric interface, allowing the attacker to access and modify arbitrary files. FG-IR-24-259 7.1 / High FortiOS An unauthenticated attacker may be able to exploit an out-of-bounds write vulnerability to cause a DoS condition. FG-IR-24-373 3.5 / Low FortiOS An unauthenticated attacker may be able to exploit an out-of-bounds read vulnerability to cause a DoS condition. FG-IR-24-266 7.5 / High FortiOS An authenticated attacker with low privileges may be able to cause a DoS condition due to two NULL pointer dereference vulnerabilities. FG-IR-23-293 6.4 / Medium FortiOS An unauthenticated attacker may be able to exploit a resource allocation vulnerability to cause a DoS condition using multiple large file uploads. FG-IR-24-219 7.1 / High FortiOS An authenticated attacker may be able to exploit an integer overflow vulnerability to cause a DoS condition. FG-IR-24-267 3.2 / Low FortiOS An authenticated attacker may be able to exploit an improper access control vulnerability. FG-IR-23-407 4.7 / Medium FortiOS, FortiProxy and FortiSASE An unauthenticated attacker may be able to exploit a http response splitting vulnerability in FortiOS, FortiProxy and FortiSASE FG-IR-24-282 6.4 / Medium FortiOS An unauthenticated attacker may be able to exploit a man-in-the-middle vulnerability to intercept sensitive information. FG-IR-24-326 3.5 / Low Identifying affected systemsA list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2024-55591 as they’re released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.
Additionally, customers can utilize Tenable Attack Surface Management to identify public facing Fortinet assets:
Get more informationJoin Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.
The post CVE-2024-55591: Fortinet Authentication Bypass Zero-Day Vulnerability Exploited in the Wild appeared first on Security Boulevard.
Authors/Presenters: Emma Stewart
Our sincere appreciation to DEF CON, and the Authors/Presenters for publishing their erudite DEF CON 32 content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.
The post DEF CON 32 – Pick Your Poison: Navigating A Secure Clean Energy Transition appeared first on Security Boulevard.
SYMMETRY CUSTOMER CASE STUDY Leading Fintech Accelerates PCI DSS 4.0 Compliance with Symmetry Systems ABOUT Industry:Fintech Size:1K – 3K employees...
The post Leading Fintech Accelerates PCI DSS 4.0 Compliance with Symmetry Systems appeared first on Symmetry Systems.
The post Leading Fintech Accelerates PCI DSS 4.0 Compliance with Symmetry Systems appeared first on Security Boulevard.
Microsoft addresses 157 CVEs in the first Patch Tuesday release of 2025 and the largest Patch Tuesday update ever with three CVEs exploited in the wild, and five CVEs publicly disclosed prior to patches being made available.
Microsoft patched 157 CVEs in its January 2025 Patch Tuesday release, with 10 rated critical and 147 rated as important. Our counts omitted two vulnerabilities, one reported by GitHub and another reported by CERT/CC. To date, the January 2025 Patch Tuesday release is the largest ever from Microsoft.
This month’s update includes patches for:
Remote code execution (RCE) vulnerabilities accounted for 36.9% of the vulnerabilities patched this month, followed by elevation of privilege (EoP) vulnerabilities at 25.5%.
Important CVE-2025-21333, CVE-2025-21334, CVE-2025-21335 | Windows Hyper-V NT Kernel Integration VSP Elevation of Privilege VulnerabilitiesCVE-2025-21333, CVE-2025-21334 and CVE-2025-21335 are EoP vulnerabilities in the Windows Hyper-V NT Kernel Integration Virtualization Service Provider (VSP). All three vulnerabilities were assigned a CVSSv3 score of 7.8 and rated important. An authenticated, local attacker could exploit this vulnerability to elevate privileges to SYSTEM. Two of the three vulnerabilities were unattributed, with CVE-2025-21333 being attributed to an Anonymous researcher.
According to Microsoft all three vulnerabilities were exploited in the wild as zero-days. No specific details about the in-the-wild exploitation were public at the time this blog post was released.
Important CVE-2025-21186, CVE-2025-21366, CVE-2025-21395 | Microsoft Access Remote Code Execution VulnerabilityCVE-2025-21186, CVE-2025-21366 and CVE-2025-21395 are RCE vulnerabilities in Microsoft Access, a database management system. All three vulnerabilities were assigned a CVSSv3 score of 7.8 and rated important. A remote, unauthenticated attacker could exploit this vulnerability by convincing a target through social engineering to download and open a malicious file. Successful exploitation would grant an attacker arbitrary code execution privileges on the vulnerable system. This update “blocks potentially malicious extensions from being sent in an email.”
According to Microsoft, these three vulnerabilities were publicly disclosed prior to a patch being available (zero-days). They are attributed to Unpatched.ai, which uses artificial intelligence (AI) to “help find and analyze” vulnerabilities.
Important CVE-2025-21308 | Windows Themes Spoofing VulnerabilityCVE-2025-21308 is a spoofing vulnerability affecting Windows Themes. This vulnerability received a CVSSv3 score of 6.5 and was publicly disclosed prior to a patch being made available. According to Microsoft, successful exploitation requires an attacker to convince a user to load a malicious file, then convince the user to “manipulate the specially crafted file.” Microsoft has provided a list of mitigations including disabling New Technology LAN Manager (NTLM) or using group policy to block NTLM hashes. For more information on the mitigation guidance, please refer to the Microsoft advisory.
Important CVE-2025-21275 | Windows App Package Installer Elevation of Privilege VulnerabilityCVE-2025-21275 is an EoP vulnerability in the Microsoft Windows App Package Installer. It was assigned a CVSSv3 score of 7.8 and is rated important. A local, authenticated attacker could exploit this vulnerability to obtain SYSTEM privileges. These types of flaws are often associated with post-compromise activity, after an attacker has breached a system through other means.
According to Microsoft, this vulnerability was publicly disclosed prior to a patch being available. It is attributed to an Anonymous researcher.
Critical CVE-2025-21297, CVE-2025-21309 | Windows Remote Desktop Services Remote Code Execution VulnerabilityCVE-2025-21297 and CVE-2025-21309 are critical RCE vulnerabilities affecting Windows Remote Desktop Services. Both of these vulnerabilities were assigned CVSSv3 scores of 8.1, however CVE-2025-21309 was assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index, while CVE-2025-21297 was assessed as “Exploitation Less Likely.”
According to Microsoft, successful exploitation of these flaws requires an attacker to connect to a system with the Remote Desktop Gateway role and trigger a race-condition that creates a use-after-free scenario which can be leveraged to execute arbitrary code.
Critical CVE-2025-21298 | Windows OLE Remote Code Execution VulnerabilityCVE-2025-21298 is a RCE vulnerability in Microsoft Windows Object Linking and Embedding (OLE). It was assigned a CVSSv3 score of 9.8 and is rated critical. It has been assessed as “Exploitation More Likely.” An attacker could exploit this vulnerability by sending a specially crafted email to a target. Successful exploitation would lead to remote code execution on the target system if the target opens this email using a vulnerable version of Microsoft Outlook or if their software is able to preview the email through a preview pane.
Microsoft’s advisory for this vulnerability recommends configuring Microsoft Outlook to read email messages “in plain text format” instead of a rich format that will display other types of content, such as photos, animations or specialized fonts. To configure Outlook in this way, please refer to the following article, Read email messages in plain text.
Tenable SolutionsA list of all the plugins released for Microsoft’s January 2025 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.
For more specific guidance on best practices for vulnerability assessments, please refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.
Get more informationJoin Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.
The post Microsoft’s January 2025 Patch Tuesday Addresses 157 CVEs (CVE-2025-21333, CVE-2025-21334, CVE-2025-21335) appeared first on Security Boulevard.
