Deny alg_socket to Containers with SELinux to Mitigate CVE‑2026‑31431

2026-05-01T12:15:18 by sync_user

JSON CVE-2026-31431

Deny alg_socket to Containers with SELinux to Mitigate CVE‑2026‑31431 | Blog•Feistel•Party

CVE-2026-31431 or “Copy Fail” is a bug in the Linux kernel’s implementation of the AF_ALG socket type that exposes the kernel’s crypto subsystem to unprivileged userspace. Because most applications don’t use this and there is a risk of container escape, it makes sense to deny access.

In the example below, I’m using the fish shell with an SELinux userspace release after 3.6 which is when support for deny rules was added.

opc@sparkling ~\> # remove rule for testing
opc@sparkling ~\> sudo semodule -r psub-container-alg
libsemanage.semanage_direct_remove_key: Removing last psub-container-alg module (no other psub-container-alg module exists at another priority).
opc@sparkling ~\> sudo podman run -ti --rm alpine/openssl engine -t -c -vv afalg
(afalg) AFALG engine support
[AES-128-CBC, AES-192-CBC, AES-256-CBC]
[ available ]
opc@sparkling ~\> sudo semodule -i (sesearch -A -s container_ -rs -c alg_socket -p create | egrep -v unconfined | sed 's/^allow/\(deny/; s/:/ \(/; s/{/\(/; s/};/)))/' | psub -s -container-alg.cil)
opc@sparkling ~\> sudo podman run -ti --rm alpine/openssl engine -t -c -vv afalg
20DD97B0FFFF0000:error:4000006D:lib(128)::reason(109):engines/e_afalg.c:882:
20DD97B0FFFF0000:error:1300006D:engine routines:dynamic_load:init failed:crypto/engine/eng_dyn.c:498:
20DD97B0FFFF0000:error:13000074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:470:id=afalg
opc@sparkling ~ [1]\> # :)
opc@sparkling ~ [1]\>

Alternative Mitigations

Red Hat suggests an initcall_blacklist in the boot arguments.

Lennart Poettering’s advice for CVE-2016-8655 should also work for CVE‑2026‑31431 by using RestrictAddressFamilies=~AF_ALG on a per-service basis. In my testing this works for both containers and other services. R-fx Networks pairs this with SystemCallArchitectures=native.

user@serv ~\> sudo systemd-run --pty --wait --collect podman run -ti --rm alpine/openssl engine -t -c -vvv afalg
Running as unit: run-u3914.service
Press ^] three times within 1s to disconnect TTY.
(afalg) AFALG engine support
[AES-128-CBC, AES-192-CBC, AES-256-CBC]
[ available ]
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 548ms
user@serv ~\> sudo systemd-run --pty --wait --collect -p 'RestrictAddressFamilies=~AF_PACKET AF_ALG' podman run -ti --rm alpine/openssl engine -t -c -vvv afalg
Running as unit: run-u3923.service
Press ^] three times within 1s to disconnect TTY.
280B94F7067F0000:error:4000006D:lib(128)::reason(109):engines/e_afalg.c:882:
280B94F7067F0000:error:1300006D:engine routines:dynamic_load:init failed:crypto/engine/eng_dyn.c:498:
280B94F7067F0000:error:13000074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:470:id=afalg
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
Service runtime: 563ms
user@serv ~ [1]\> sudo systemd-run --pty --wait --collect openssl engine -t -c -vvv afalg
Running as unit: run-u3932.service
Press ^] three times within 1s to disconnect TTY.
(afalg) AFALG engine support
[AES-128-CBC, AES-192-CBC, AES-256-CBC]
[ available ]
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 8ms
user@serv ~\> sudo systemd-run --pty --wait --collect -p 'RestrictAddressFamilies=~AF_PACKET AF_ALG' openssl engine -t -c -vvv afalg
Running as unit: run-u3935.service
Press ^] three times within 1s to disconnect TTY.
139718332651328:error:8006406D:lib(128):func(100):reason(109):engines/e_afalg.c:800:
139718332651328:error:260B606D:engine routines:dynamic_load:init failed:crypto/engine/eng_dyn.c:485:
139718332651328:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:334:id=afalg
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
Service runtime: 7ms
user@serv ~ [1]\>

Questions about SELinux

Why was support for deny rules only added to the SELinux userspace in 2023?

Why is the output of `sesearch` so dissimilar to the input of `semanage` ?

What is the purpose of `allow unconfined_domain_type domain:alg_socket` and does leaving this rule alone ruin the mitigation?

opc@sparkling ~\> seinfo -a unconfined_domain_type -x | grep -E '(contain|^\w|^\s{3})\w'
Type Attributes: 1
attribute unconfined_domain_type;
container_runtime_t
opc@sparkling ~\>

This relates to container_runtime_t. This is for privileged containers in rootless mode and for the container management engine itself. So it’s probably OK.

Quick remediation

2026-04-30T10:07:37 by sync_user

JSON CVE-2026-31431

Kernel module (without reboot)

If your system use dynamic loading of kernel module, the following can be done:

rmmod algif_aead to ensure that the module is not loaded

Create and edit the file /etc/modprobe.d/disable-algif.conf and add install algif_aead /bin/false

Kernel with algif_aead (such as RedHat)

Based on the following https://csirt.egi.eu/2026/04/30/critical-vulnerability-in-linux-kernel/ reference, this can be done:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"; sudo reboot"

which will require a reboot.

BPF filtering

There are also options there.

Authentication Vulnerability in FortiOS, FortiProxy, and FortiSwitchManager leads to Unauthenticated Admin Access

2025-05-15T12:16:29 by sync_user

JSON CVE-2025-22252

Risks

FortiOS, FortiProxy, and FortiSwitchManager are core components of Fortinet’s network security and management infrastructure, which provide firewalling, proxy services, and centralized switch management.

CVE-2025-22252 is a missing authentication vulnerability that allows an unauthenticated attacker with knowledge of an existing admin account to access the device as a valid admin. Exploitation of this flaw could grant attackers unauthorized control over network infrastructure, threatening confidentiality through data exposure, integrity via configuration tampering, and availability by disrupting critical services.

Description

CVE-2025-22252 is a missing authentication for critical function vulnerability in devices configured to use a remote TACACS+ server for authentication configured to use ASCII authentication. It may allow an attacker with knowledge of an existing admin account to access the device as a valid admin via an authentication bypass, potentially resulting in complete system compromise, data theft and service disruption.

PH65941:IBM WebSphere Application Server is vulnerable to server-side request forgery (CVE-2025-27907 CVSS 4.1)

2025-04-22T15:05:24 by sync_user

JSON CVE-2025-27907

Abstract IBM WebSphere Application Server is vulnerable to server-side request forgery (CVE-2025-27907 CVSS 4.1)

Download Description

PH65941 resolves the following problem:

ERROR DESCRIPTION: IBM WebSphere Application Server is vulnerable to server-side request forgery (CVE-2025-27907 CVSS 4.1)

PROBLEM SUMMARY: IBM WebSphere Application Server is vulnerable to server-side request forgery (CVE-2025-27907 CVSS 4.1)

PROBLEM CONCLUSION: Confidential for CVE-2025-27907.

The fix for this APAR is targeted for inclusion in 8.5.5.28, 9.0.5.24.

For more information, see Recommended Updates for WebSphere Application Server: https://www.ibm.com/support/pages/node/715553

Prerequisites None

Problems Solved PH65941

Source: https://www.ibm.com/support/pages/node/7231182

Apache Pinot Improper Neutralization of Special Elements Authentication Bypass Vulnerability

2025-03-11T05:25:53 by sync_user

JSON CVE-2024-56325

CVE ID CVE-2024-56325 CVSS SCORE 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H AFFECTED VENDORS Apache AFFECTED PRODUCTS Pinot VULNERABILITY DETAILS
This vulnerability allows remote attackers to bypass authentication on affected installations of Apache Pinot. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the AuthenticationFilter class. The issue results from insufficient neutralization of special characters in a URI. An attacker can leverage this vulnerability to bypass authentication on the system.

ADDITIONAL DETAILS
Fixed in version 1.3.0

PaloAlto - CVE-2024-3393 PAN-OS: Firewall Denial of Service (DoS) in DNS Security Using a Specially Crafted Packet

2024-12-27T08:59:02 by sync_user

JSON CVE-2024-3393

CVE-2024-3393 PAN-OS: Firewall Denial of Service (DoS) in DNS Security Using a Specially Crafted Packet

Ref: https://security.paloaltonetworks.com/CVE-2024-3393

A Denial of Service vulnerability in the DNS Security feature of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to send a malicious packet through the data plane of the firewall that reboots the firewall. Repeated attempts to trigger this condition will cause the firewall to enter maintenance mode.

See the Solution section for additional fixes to commonly deployed maintenance releases.

DNS Security logging must be enabled for this issue to affect PAN-OS software.

Palo Alto Networks is aware of customers experiencing this denial of service (DoS) when their firewall blocks malicious DNS packets that trigger this issue.

This issue is fixed in PAN-OS 10.1.14-h8, PAN-OS 10.2.10-h12, PAN-OS 11.1.5, PAN-OS 11.2.3, and all later PAN-OS versions.

Note: PAN-OS 11.0 reached the end of life (EOL) on November 17, 2024, so we do not intend to provide a fix for this release.

Prisma Access customers using DNS Security with affected PAN-OS versions should apply one of the workarounds provided below. We will perform upgrades in two phases for impacted customers on the weekends of January 3rd and January 10th. You can request an expedited Prisma Access upgrade to the latest PAN-OS version by opening a support case.

In addition, to provide the most seamless upgrade path for our customers, we are making fixes available for other TAC-preferred and commonly deployed maintenance releases.

Remember to revert the Log Severity settings once the fixes are applied.

Until we perform an upgrade of your Prisma Access tenant, you can disable DNS Security logging across all NGFWs in your tenant by opening a support case. If you would like to expedite the upgrade, please make a note of that in the support case.

cpe:2.3:o:paloaltonetworks:pan-os:11.2.2:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.2.2:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.2.1:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.2.1:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.2.0:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.2.0:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.2:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h9:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h8:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h7:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.4:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h11:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h10:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h9:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h8:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h7:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.3:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h15:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h14:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h13:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h12:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h11:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h10:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h9:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h8:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h7:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.2:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.1:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.1:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.1:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.0:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.0:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.0:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.0:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1.0:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:11.1:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h10:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h9:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h8:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h7:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.10:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h18:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h17:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h16:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h15:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h14:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h13:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h12:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h11:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h10:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h9:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h8:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h7:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.9:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h18:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h17:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h16:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h15:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h14:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h13:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h12:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h11:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h10:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h9:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h8:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h7:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2.8:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.2:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:h6:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:h5:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:h4:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:h3:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:h2:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:h1:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1.14:-:*:*:*:*:*:*

cpe:2.3:o:paloaltonetworks:pan-os:10.1:-:*:*:*:*:*:*

CVE-2023-50164 - Rapid7 analysis

2024-12-19T05:35:41 by sync_user

JSON CVE-2023-50164

Reference - https://attackerkb.com/topics/pe3CCtOE81/cve-2023-50164/rapid7-analysis

Apache Struts is a popular Java web application framework. On December 7, 2023 Apache published an advisory for CVE-2023-50164, a Struts parameter pollution vulnerability that potentially leads to arbitrary file uploads. An attacker with the ability to perform arbitrary file uploads is very likely to be able to leverage this and achieve remote code execution. According to the vendor, the following versions of Struts are affected:

Struts 2.0.0 – Struts 2.3.37 (End of Life)
Struts 2.5.0 – Struts 2.5.32
Struts 6.0.0 – Struts 6.3.0

Several technical analyses on the root cause of the vulnerability have already been done (here, here, and here). Notably, all current public analysis of the vulnerability demonstrates exploitation on a custom made demo web application.

There are currently no known production web applications that are exploitable, although this is likely to change as the vulnerability comes under more scrutiny from researchers, and given the popularity of the Struts framework in enterprise web applications. Several security firms have reported exploitation (here and here), but as of December 15, 2023, it is unclear if the activity being reported actually refers to successful exploitation (i.e., code execution) against one or more known vulnerable targets, or if this is merely highlighting exploit attempts with the existing public PoCs (all of which target a demo application) being sprayed opportunistically at indiscriminate targets.

However, exploitation of this vulnerability will be target-specific based on the differing target action’s endpoints, the naming convention of the expected uploaded file name, and any other target-specific restrictions that may need to be overcome.

Remediation

Vendors who develop applications that use Apache Struts should upgrade to Struts 2.5.33, Struts 6.3.0.2, or greater to remediate CVE-2023-50164.

(Vendor information) Missing authentication in fgfmsd

2024-10-25T07:11:40 by sync_user

JSON CVE-2024-47575

A missing authentication for critical function vulnerability [CWE-306] in FortiManager fgfmd daemon may allow a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests.

Reports have shown this vulnerability to be exploited in the wild.

PSIRT | FortiGuard Labs 9–11 minutes Summary

A missing authentication for critical function vulnerability [CWE-306] in FortiManager fgfmd daemon may allow a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests.

Reports have shown this vulnerability to be exploited in the wild. Version Affected Solution FortiManager 7.6 7.6.0 Upgrade to 7.6.1 or above FortiManager 7.4 7.4.0 through 7.4.4 Upgrade to 7.4.5 or above FortiManager 7.2 7.2.0 through 7.2.7 Upgrade to 7.2.8 or above FortiManager 7.0 7.0.0 through 7.0.12 Upgrade to 7.0.13 or above FortiManager 6.4 6.4.0 through 6.4.14 Upgrade to 6.4.15 or above FortiManager 6.2 6.2.0 through 6.2.12 Upgrade to 6.2.13 or above FortiManager Cloud 7.6 Not affected Not Applicable FortiManager Cloud 7.4 7.4.1 through 7.4.4 Upgrade to 7.4.5 or above FortiManager Cloud 7.2 7.2.1 through 7.2.7 Upgrade to 7.2.8 or above FortiManager Cloud 7.0 7.0.1 through 7.0.12 Upgrade to 7.0.13 or above FortiManager Cloud 6.4 6.4 all versions Migrate to a fixed release

Old FortiAnalyzer models 1000E, 1000F, 2000E, 3000E, 3000F, 3000G, 3500E, 3500F, 3500G, 3700F, 3700G, 3900E with the following feature enabled (FortiManager on FortiAnalyzer):

config system global set fmg-status enable end

and at least one interface with fgfm service enabled are also impacted by this vulnerability.

Workarounds

Upgrade to a fixed version or use one of the following workarounds, depending on the version you're running:

1- For FortiManager versions 7.0.12 or above, 7.2.5 or above, 7.4.3 or above (but not 7.6.0), prevent unknown devices to attempt to register:

config system global (global)# set fgfm-deny-unknown enable (global)# end

Warning: With this setting enabled, be aware that if a FortiGate's SN is not in the device list, FortiManager will prevent it from connecting to register upon being deployed, even when a model device with PSK is matching.

If FAZ features are enabled on FMG, block the addition of unauthorized devices via syslog:

conf system global set detect-unregistered-log-device disable end

If FortiGate Updates or Web Filtering are enabled, block the addition of unauthorized devices via FDS:

conf fmupdate fds-setting set unreg-dev-option ignore end

2- Alternatively, for FortiManager versions 7.2.0 and above, you may add local-in policies to whitelist the IP addresses of FortiGates that are allowed to connect.

Example:

config system local-in-policy edit 1 set action accept set dport 541 set src next edit 2 set dport 541 next end

3- For 7.2.2 and above, 7.4.0 and above, 7.6.0 and above it is also possible to use a custom certificate which will mitigate the issue:

config system global set fgfm-ca-cert set fgfm-cert-exclusive enable

end

And install that certificate on FortiGates. Only this CA will be valid, this can act as a workaround, providing the attacker cannot obtain a certificate signed by this CA via an alternate channel.

NB: For FortiManager versions 6.2, 6.4, and 7.0.11 and below, please upgrade to one of the versions above and apply the above workarounds.

Indicators of Compromise

The following are possible IoCs:

Log entries

type=event,subtype=dvm,pri=information,desc="Device,manager,generic,information,log",user="device,...",msg="Unregistered device localhost add succeeded" device="localhost" adom="FortiManager" session_id=0 operation="Add device" performed_on="localhost" changes="Unregistered device localhost add succeeded"

type=event,subtype=dvm,pri=notice,desc="Device,Manager,dvm,log,at,notice,level",user="System",userfrom="",msg="" adom="root" session_id=0 operation="Modify device" performed_on="localhost" changes="Edited device settings (SN FMG-VMTM23017412)"

IP addresses

45.32.41.202 104.238.141.143 158.247.199.37 45.32.63.2 195.85.114.78 (Not observed by Fortinet, reported by Mandiant here)

Serial Number

FMG-VMTM23017412

Files

/tmp/.tm /var/tmp/.tm

Note that file IoCs may not appear in all cases.

Risk

The identified actions of this attack in the wild have been to automate via a script the exfiltration of various files from the FortiManager which contained the IPs, credentials and configurations of the managed devices.

At this stage, we have not received reports of any low-level system installations of malware or backdoors on these compromised FortiManager systems. To the best of our knowledge, there have been no indicators of modified databases, or connections and modifications to the managed devices.

Recovery

A FortiManager configuration backup file would not contain any OS or system-level file changes, as these files are not included in the archive. Therefore, taking a backup from a compromised system and then restoring it on a fresh or re-initialized one, would not carry over and re-introduce such low-level changes. When taking this approach, be aware that the data may have been tampered with. Careful review should be done to confirm configuration accuracy.

The methods below assume that the managed devices (FortiGates or other) contained in the backup have not been tampered with and that their configurations are reliable. Event log activity verification of the FortiGates should be reviewed starting from the date of the identified IoCs, to determine if there were any unauthorized access or configuration changes. Since data may have been exfiltrated from the FortiManager database, we recommend that the credentials, such as passwords and user-sensitive data, of all managed devices, be urgently changed.

For VM installations, recovery can be facilitated by keeping a copy of the compromised FortiManager in an isolated network with no Internet connection, as well as configuring it in offline mode and closed-network mode operation (see settings below). This system can be used to compare with the new one which will be set up in parallel.

config system admin setting set offline_mode enable end config fmupdate publicnetwork set status disable end

Recovery Methods

Option 1 – Recommended Recovery Action

This method ensures that the FortiManager configuration was not tampered with. It will require database rebuilding or device configuration resynchronizations at the Device and Policy Package ADOM levels.

• Installing a fresh FortiManager VM or re-initializing a hardware model and adding/discovering the devices. • Installing a fresh FortiManager VM or re-initializing a hardware model, and restoring a backup taken before the IoC detection.

Option 2 – Alternative Recovery Action

This method provides a quick recovery, where partial or no database rebuilding/resynchronization is required. It requires that you manually verify accuracy of the currently running FortiManager configuration

• Installing a fresh FortiManager VM or re-initializing a hardware model and restoring/copying components or configuration sections from a compromised FortiManager. • Installing a fresh FortiManager VM or re-initializing a hardware model, and restoring a backup from a compromised FortiManager.

For more info on data configuration and synchronization procedures: https://community.fortinet.com/t5/FortiManager/Technical-Tip-FortiManager-data-configuration-and/ta-p/351748

https://www.fortiguard.com/psirt/FG-IR-24-423

Patches released previously did not completely mitigate the vulnerability

2024-10-22T13:20:32 by sync_user

JSON CVE-2024-38812

VMware has determined that the vCenter patches released previously did not completely mitigate the vulnerability.

https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24968

Availability of a patch

2024-10-18T22:25:32 by sync_user

JSON CVE-2024-28987

The company released a patch in Web Help Desk version 12.8.3 HF2, which addresses this vulnerability. Users are strongly advised to update their software to this version or later to protect against this flaw.

Recent comments