company logo

Product

Our Product

We are Reshaping the way Developers find and fix vulnerabilities before they get exploited.

Solutions

By Industry

BFSI

Healthcare

Education

IT & Telecom

Government

By Role

CISO/CTO

DevOps Engineer

Resources

Resource Library

Get actionable insight straight from our threat Intel lab to keep you informed about the ever-changing Threat landscape.

Subscribe to Our Weekly Threat Digest

Company

Contact Us

Have queries, feedback or prospects? Get in touch and we shall be with you shortly.

loading..
loading..
loading..
Loading...

hhh

loading..
loading..
loading..

zzh

Ttt

24-Oct-2024
1 min read

Related Articles

loading..

FortiJump

zero day

Comprehensive technical analysis of FortiManager zero-day CVE-2024-47575 ("Forti...

A critical zero-day vulnerability in Fortinet's FortiManager, dubbed `FortiJump` and tracked as CVE-2024-47575, has been actively exploited by nation-state actors to conduct espionage via Managed Service Providers (MSPs). The flaw allows attackers to execute arbitrary code or commands on FortiManager systems, potentially compromising managed FortiGate firewalls and downstream networks. This comprehensive [Threatfeed](https://www.secureblink.com/cyber-security-news) combines actionable insights from cybersecurity professional and official advisories to provide a detailed analysis of the vulnerability, its exploitation methods, affected versions, mitigation strategies, and the broader implications for organizations using Fortinet products. ### Overview of the Vulnerability #### What is FortiManager? FortiManager is a centralized management platform that enables organizations to manage multiple FortiGate firewalls and other Fortinet devices. It uses the FortiGate to FortiManager (FGFM) protocol to facilitate communication and management tasks, especially in environments with Network Address Translation (NAT). ### Nature of the Vulnerability - **Type:** Missing authentication for a critical function (CWE-306) in the FortiManager fgfmd daemon. - **CVE Identifier:** CVE-2024-47575 - **Severity:** Rated 9.8 out of 10 (Critical). - **Affected Protocol:** FGFM (FortiGate to FortiManager Protocol) - **Impact:** Allows remote, unauthenticated attackers to execute arbitrary code or commands via specially crafted requests. ### Exploitation Requirements Attackers must first obtain a valid certificate from any owned or compromised Fortinet device (e.g., FortiGate firewall, FortiManager VM). The vulnerability lies in an authentication bypass within the FGFM API, enabling attackers to execute commands without proper authorization. ### Technical Details #### How the Exploit Works - **1. Certificate Acquisition:** Attackers obtain a valid certificate from a Fortinet device. This certificate is used to establish an SSL tunnel between the FortiGate device and FortiManager, authenticating both devices. - **2. Registration of Rogue Devices:** Using the valid certificate, attackers can register a rogue FortiGate device with the FortiManager, often appearing under the name _"localhost"_. - **3. API Exploitation:** The vulnerability allows attackers to bypass authentication checks in the FGFM API, enabling them to execute arbitrary commands on the FortiManager. - **4. Lateral Movement:** Once inside FortiManager, attackers can access configurations, IP addresses, and credentials of managed FortiGate devices, potentially compromising downstream networks. #### Potential for Espionage MSPs often use FortiManager to manage client networks. By exploiting this vulnerability, attackers can infiltrate MSPs and access their clients' networks, facilitating large-scale espionage. Evidence suggests that nation-state actors are exploiting this vulnerability for espionage purposes. ### Impact and Potential Damage #### Data Theft Sensitive Information Exposure: Attackers can steal files containing configurations, IP addresses, and credentials of managed devices. - **Network Mapping:** Access to configurations and IP addresses allows attackers to map the network infrastructure for further exploitation. #### Control Over Managed Devices Unauthorized Access: Attackers can gain control over managed FortiGate devices, enabling them to alter configurations, deploy malicious policies, or disable security features. - **Lateral Movement:** With control over FortiGate devices, attackers can move laterally within the network, potentially accessing sensitive internal systems. #### Difficulty in Detection - The use of valid certificates and legitimate protocols makes detection challenging. - Fortinet reports no evidence of malware installation or configuration changes, making it harder for organizations to identify compromises. ### Affected Versions #### FortiManager 7.6.0: Upgrade to 7.6.1 or above. 7.4.0 to 7.4.4: Upgrade to 7.4.5 or above. 7.2.0 to 7.2.7: Upgrade to 7.2.8 or above. 7.0.0 to 7.0.12: Upgrade to 7.0.13 or above. 6.4.0 to 6.4.14: Upgrade to 6.4.15 or above. 6.2.0 to 6.2.12: Upgrade to 6.2.13 or above. #### FortiManager Cloud 7.4.1 to 7.4.4: Upgrade to 7.4.5 or above. 7.2.1 to 7.2.7: Upgrade to 7.2.8 or above. 7.0.1 to 7.0.12: Upgrade to 7.0.13 or above. 6.4 All Versions: Migrate to a fixed release. **Note:** _As of the latest update, only versions 7.2.8 and 7.4.5 have patches available. Patches for other versions are expected to be released in the coming days._ ### Mitigation and Recommendations #### Immediate Actions **1. Apply Patches** Install the latest patches provided by Fortinet for your specific version. Continuously monitor for new patches and updates, especially if your version's patch is pending. **2. Disable Automatic Registration of Unknown Devices** Use set fgfm-deny-unknown enable to prevent devices with unknown serial numbers from registering with FortiManager. This setting may not be effective on versions 7.6.0 and 6.4.14. **3. Use Custom Certificates** Deploy custom certificates for SSL tunnel authentication between FortiGate devices and FortiManager. If attackers obtain these certificates, they could still exploit the vulnerability. **4. Restrict IP Access** Configure FortiManager to accept connections only from trusted IP addresses of known FortiGate devices. Set up firewall rules to block unauthorized access to FGFM ports (TCP 541 for IPv4 and TCP 542 for IPv6). ### Monitoring and Detection 1. Check for Unregistered Devices Named "localhost" Rogue devices may appear under the name "localhost" in the Unregistered Devices section. 2. Review Log Entries Look for log entries indicating the addition or modification of devices without authorization. ### Sample Log Entries: Unregistered device "localhost" added. Device settings edited for a device with serial number resembling FMG-VMTM23017412. 3. Search for Specific Files Indicator Files: Presence of /tmp/.tm and /var/tmp/.tm may indicate exploitation. 4. Monitor Network Traffic Suspicious IP Addresses: Watch for connections from the following IPs associated with known attacks: 45.32.41.202 104.238.141.143 (associated with SuperShell C2 infrastructure) 158.247.199.37 45.32.63.2 5. Analyze FortiGate Device Behavior Unusual Activity: Check for any abnormal configurations or policies pushed to FortiGate devices. Long-Term Measures 1. Restrict FGFM Exposure Avoid Internet Exposure: Do not expose FGFM ports directly to the internet. Use VPNs or dedicated management networks. NAT Considerations: Review NAT configurations to ensure they do not inadvertently expose FGFM services. 2. Enhance Authentication Mechanisms Multi-Factor Authentication (MFA): Implement MFA for administrative access to FortiManager. Strong Password Policies: Enforce complex passwords and regular changes. 3. Regular Security Audits Configuration Reviews: Periodically audit FortiManager and FortiGate configurations for unauthorized changes. Compliance Checks: Ensure adherence to security best practices and regulatory requirements. 4. Employee Training Security Awareness: Educate staff about potential threats and encourage prompt reporting of suspicious activities. Indicators of Compromise (IOCs) Known Malicious IPs 45.32.41.202 104.238.141.143 158.247.199.37 45.32.63.2 Suspicious Serial Numbers Devices registering with serial numbers like FMG-VMTM23017412. Malicious Activities Unregistered Devices Added: Devices named "localhost" appearing in FortiManager. Configuration Changes: Unauthorized edits to device settings. Presence of Specific Files: /tmp/.tm and /var/tmp/.tm. Response from Fortinet and Community Reaction Fortinet's Actions Private Disclosure: Initially, Fortinet privately notified customers via emails starting October 13, 2024. Public Advisory: On October 23, 2024, Fortinet publicly disclosed the vulnerability and released the advisory FG-IR-24-423. Patches Released: Provided patches for versions 7.2.8 and 7.4.5, with more forthcoming. Community Concerns Lack of Transparency: Customers expressed frustration over the private disclosure, with some not receiving notifications. Delayed Patching: Criticism over the time taken to release patches for all affected versions. Past Incidents: Fortinet has previously faced scrutiny for similar handling of critical vulnerabilities. Fortinet's Statement Fortinet emphasized their commitment to responsible disclosure, aiming to protect customers by providing mitigation steps before public release. They are coordinating with government agencies and industry organizations as part of their response. Broader Implications Risk to Managed Service Providers (MSPs) Supply Chain Attacks: Compromising an MSP can provide attackers access to multiple client networks. Espionage Potential: Nation-state actors can leverage this vulnerability for intelligence gathering. Prevalence of Exposed Devices Shodan Data: Approximately 60,000 FGFM devices are internet-facing. Geographical Distribution: Majority located in the United States. Importance of Timely Patching Exploitation Window: Delays in patching increase the risk of exploitation. Historical Neglect: Previous vulnerabilities like CVE-2023-27997 remain unpatched in many systems. Conclusion The CVE-2024-47575 vulnerability in Fortinet's FortiManager is a critical security issue that demands immediate attention. The active exploitation by sophisticated threat actors underscores the importance of prompt patching, vigilant monitoring, and robust security practices. Organizations using FortiManager and FortiGate products should: Act Quickly: Apply patches or implement mitigations without delay. Enhance Security Posture: Review and strengthen security configurations. Stay Informed: Monitor official advisories and community discussions for updates. By taking proactive measures, organizations can mitigate the risks posed by this vulnerability and protect their networks from potential espionage and cyber-attacks. Additional Resources Fortinet PSIRT Advisory: FG-IR-24-423 CISA Known Exploited Vulnerabilities Catalog: CISA KEV Catalog Cybersecurity Community Discussions: Reddit threads on Fortinet vulnerabilities. Security researchers' analyses on platforms like Mastodon. References Fortinet Official Communications Kevin Beaumont's Analysis on "FortiJump" Lawrence Abrams' Reporting on BleepingComputer Community Reports and Discussions

loading..   23-Oct-2024
loading..   8 min read
loading..

NPM

Ethereum

Malicious npm packages impersonate popular Ethereum libraries to steal private k...

Recent investigations have revealed two separate but related attacks targeting the Ethereum developer community through malicious npm packages. These attacks involve typosquatting popular Ethereum libraries and inserting malicious code to exfiltrate private keys and compromise developer systems. Understanding these incidents is crucial for safeguarding projects and personal security in the blockchain ecosystem. ### First Attack: Trojanized Ethers Forks Attempting to Steal Private Keys A series of malicious packages were [published](https://blog.phylum.io/trojanized-ethers-forks-on-npm-attempting-to-steal-ethereum-private-keys/) on npm impersonating the widely used [ethers library](https://www.npmjs.com/package/ethers), which facilitates interaction with the Ethereum blockchain and has over 1.3 million weekly downloads. The attacker created packages with names similar to the legitimate library: - `[ethers-mew](https://npm-stat.com/charts.html?package=ethers-mew)` - `[ethers-web3](https://npm-stat.com/charts.html?package=ethers-web3)` - `[ethers-6](https://npm-stat.com/charts.html?package=ethers-6)` - `[ethers-eth](https://npm-stat.com/charts.html?package=ethers-eth)` - `[ethers-aaa](https://npm-stat.com/charts.html?package=ethers-aaa)` - `[ethers-audit](https://npm-stat.com/charts.html?package=ethers-audit)` - `[ethers-test](https://npm-stat.com/charts.html?package=ethers-test)` These packages contain malicious code designed to: - **1. Exfiltrate Ethereum Private Keys:** When a developer instantiated a new Wallet using the malicious library, the code would send the private key to a remote server controlled by the attacker (https://ether-sign.com/api/checkServer). - **2. Gain Unauthorized SSH Access:** The malware attempted to append the attacker's SSH public key to the root user's authorized_keys file, potentially granting the attacker remote SSH access to the developer's machine. ### Technical Details - **Wallet Constructor Modification:** The Wallet class in the malicious package includes additional code that calls a function checkAddress with the private key as an argument. - **Layered Indirection:** The checkAddress function calls another function checkServer, which makes an HTTP POST request to the attacker's server, sending the private key. - **SSH Key Insertion:** A function named superSignKey writes the attacker's SSH public key to the root user's authorized_keys file. - **Obfuscation Tactics:** The attacker uses plausible function names and mimics the structure of the legitimate ethers library to avoid detection. The malicious code is spread across multiple files and modules, making it harder to trace. ### Indicators of Compromise (IOCs) - **Malicious Domain:** ether-sign.com (Registered on October 15, 2023) - **IP Address:** 88.99.95.50 (Hosted on Hetzner Online) - **Attacker's SSH Public Key:** An SSH key associated with the username cp@DESKTOP-7BQLEIP is inserted into the authorized_keys file. --- ### Second Attack: Typosquat of Ethereum-Cryptography Package Sending Private Keys to Remote Server An earlier attack involved typosquatting the widely-used ethereum-cryptography package, which has over 1.2 million downloads and contains cryptographic primitives essential for Ethereum development. The attacker published malicious packages with names similar to the legitimate package: - `ethereum-cryptographyy (note the extra 'y')` - `ethereum-cryptographyyy` Additionally, the attacker created a malicious version of a critical dependency: @jackshanyeshuzi/curvess (typosquat of @noble/curves) ### Malicious Activities - **1. Exfiltration of Private Keys:** The attacker modified the cryptographic functions to send private keys to a server located in China (wallet.cba123.cn). - **2. Maintaining Core Functionality:** The malicious packages retained all the legitimate functionalities to avoid raising suspicion, with the only addition being the code that exfiltrates the private key. - **3. Attempted Obfuscation:** In later versions, the attacker attempted to obfuscate the malicious code, although the obfuscation was relatively amateurish and could still be deciphered upon close inspection. ### Technical Details - **Modified Dependencies:** The attacker changed the package's dependencies to point to the malicious @jackshanyeshuzi/curvess instead of the legitimate @noble/curves. - **Insertion of Malicious Code:** Within the cryptographic functions, specifically in files like weierstrass.js, the attacker inserted code that sends the user's private key to the remote server. - **Server Location:** The domain wallet.cba123.cn is registered in China, and WHOIS records confirm its location. ### Indicators of Compromise (IOCs) Malicious Domain: wallet.cba123.cn Affected Packages and Versions: Multiple versions of `ethereum-cryptographyyy` and @jackshanyeshuzi/curvess were published over a short period. ### Timeline of Malicious Activity - **August 3, 2023:** Initial publication of @jackshanyeshuzi/curvess and ethereum-cryptographyy. - **August 4, 2023:** Multiple updates and additional malicious packages published. The attacker unpublished some packages shortly after publishing them, possibly to avoid detection. --- ### Comparative Analysis #### Attack Vectors Both attacks leveraged typosquatting, creating packages with names similar to popular libraries to deceive developers into installing them. The attackers exploited the trust developers place in widely-used open-source packages, especially those related to cryptography. #### Malicious Payloads - **Private Key Exfiltration:** The primary goal in both attacks was to steal Ethereum private keys, which could lead to immediate financial loss and compromise of blockchain assets. - **System Compromise:** The first attack also attempted to gain SSH access to the developer's machine, potentially allowing the attacker to execute arbitrary commands and access sensitive data. ### Obfuscation Techniques Both attackers attempted to hide their malicious code within legitimate-looking functions and modules. They used plausible function names and maintained the overall structure of the original libraries to avoid detection during casual code reviews. #### Differences The first attack was more aggressive in attempting to gain system-level access through SSH key insertion. The second attack focused solely on exfiltrating private keys and tried to maintain a low profile by keeping the malicious code changes minimal. ### Recommendations #### 1. Vigilance in Dependency Management - **Verify Package Names:** Pay close attention to package names to avoid typosquatting traps. Even a single character difference can indicate a malicious package. - **Check Package Metadata:** Review the number of downloads, version history, and publisher information. New packages with low download counts and recent publication dates should be treated with caution. #### 2. Use Trusted Sources - **Official Repositories:** Whenever possible, use packages from verified publishers or official repositories. - **Package Signing:** Consider using packages that are signed or verified through checksum to ensure integrity. #### 3. Code Review - **Inspect Dependencies:** Before adding new dependencies, especially those handling sensitive operations like cryptography, review the source code if feasible. - **Automated Scanning Tools:** Utilize security tools that can automatically scan dependencies for known vulnerabilities or malicious code patterns. #### 4. Network Monitoring - **Monitor Outgoing Traffic:** Use network monitoring solutions to detect and block unauthorized outbound requests to unknown domains. - **Alert on Suspicious Activity:** Set up alerts for unusual network activities, such as HTTP requests to domains not associated with your development work. #### 5. System Security Practices - **Regular Audits:** Periodically audit system files like authorized_keys to detect unauthorized modifications. - **Least Privilege Principle:** Avoid running development tools and applications with root or administrator privileges unless necessary. - **Update and Patch:** Keep your systems and applications updated to protect against known vulnerabilities. #### 6. Community Awareness - **Report Suspicious Packages:** If you discover a malicious package, report it to the package registry and the wider community. - **Stay Informed:** Keep abreast of security advisories and reports from reputable sources within the developer community.

loading..   23-Oct-2024
loading..   6 min read
loading..

GitLab

Access Token

An analysis of the Internet Archive's data breach via exposed GitLab tokens, com...

The [Internet Archive](https://www.secureblink.com/cyber-security-news/internet-archive-hacked-31-million-users-exposed), a cornerstone of digital preservation, has experienced another significant data breach. This time, the breach occurred through their Zendesk email support platform after threat actors exploited exposed [GitLab](https://www.secureblink.com/cyber-security-news/gitlab-addressed-a-critical-ssrf-flaw-discovered-to-expose-the-orgs'-internal-servers) authentication tokens. Despite prior warnings, the organization failed to rotate these tokens adequately, leading to unauthorized access to sensitive data. ### Background of the Internet Archive Breach Beginning last night, numerous individuals reported receiving unexpected emails in response to old [support tickets](https://developer.zendesk.com/api-reference/ticketing/tickets/ticket-attachments/#show-attachment) submitted to the Internet Archive. These emails, originating from the organization's official Zendesk server, alerted users to the breach: >>> _"It's dispiriting to see that even after being made aware of the breach weeks ago, IA has still not done the due diligence of rotating many of the API keys that were exposed in their gitlab secrets. As demonstrated by this message, this includes a Zendesk token with perms to access 800K+ support tickets sent to info@archive.org since 2018."_ The threat actor emphasized the magnitude of the breach, highlighting access to over 800,000 support tickets submitted since 2018. The authenticity of these emails was verified through email headers that passed all DKIM, DMARC, and SPF authentication checks, confirming they were sent from an authorized Zendesk server. ### Exposure of Personal Identifiable Information (PII) Compounding the severity of the breach, some users had previously uploaded personal identification documents when requesting the removal of content from the Wayback Machine. Depending on the level of access the threat actor had within Zendesk, these sensitive attachments might now be compromised. ![zendesk-emails.jpg](https://sb-cms.s3.ap-south-1.amazonaws.com/zendesk_emails_7a398d2ed5.jpg) ***Email snapshot sent by threat actor to Internet Archive Zendesk (Source: BleepingComputer)*** The Zendesk Attachments API allows users to upload files to support tickets, which are then accessible through links in the agent interface and notification emails. Attachments are represented as JSON objects containing details like file_name, content_type, and content_url. If the threat actor exploited this API, they could have downloaded personal documents submitted by users. ### Timeline and Failure to Act BleepingComputer attempted repetatively to [warn](https://www.bleepingcomputer.com/news/security/internet-archive-breached-again-through-stolen-access-tokens/) the Internet Archive about the exposed GitLab authentication tokens. On October 9th, they reported that the Internet Archive suffered two simultaneous attacks: - 1. A data breach compromising user data for 33 million users. - 2. A DDoS attack orchestrated by a pro-Palestinian group named SN_BlackMeta. While these attacks transpired concurrently, they were perpetrated by different threat actors. Misreporting led many to incorrectly attribute the data breach to SN_BlackMeta, frustrating the actual hacker who then reached out to Secure Blink to claim responsibility and provide details. ![js-alert.jpg](https://sb-cms.s3.ap-south-1.amazonaws.com/js_alert_70e8ef5478.jpg) ***Data Breach Notification on Internet Archive JavaScript Alert (Source: BleepingComputer)*** ### Mechanism of the Breach The initial point of compromise was an exposed GitLab configuration file on one of the Internet Archive's development servers (services-hls.dev.archive.org). This file contained an authentication token that had been exposed since at least December 2022. The threat actor used this token to download the Internet Archive's source code. ![gitlab-token.jpg](https://sb-cms.s3.ap-south-1.amazonaws.com/gitlab_token_9b779b3389.jpg) ***Internet Archive Exposed GitLab Authentication Token (Source: BleepingComputer)*** Within the source code, additional credentials and authentication tokens were discovered, including those for the organization's database management system. This access allowed the hacker to: ### Download the user database. #### Access further source code. **Modify the website.** The threat actor claims to have exfiltrated 7TB of data, though no samples were provided for verification. The inclusion of API access tokens for the Internet Archive's Zendesk support system in the stolen data further exacerbated the situation. **Negligence in Security Practices** Despite multiple warnings from Secure Blink, the Internet Archive failed to rotate the compromised authentication tokens promptly. The threat actor highlighted this negligence in their communication: >> _"Whether you were trying to ask a general question, or requesting the removal of your site from the Wayback Machine, your data is now in the hands of some random guy. If not me, it'd be someone else."_ This statement attempts to underscores the critical importance of proactive security measures and timely responses to potential threats. ### Understanding the Zendesk Attachments API Vulnerability The Zendesk Attachments API is designed to facilitate the uploading and attaching of files to support ticket comments. Key functionalities include: - **Uploading Files:** Users can upload files and attach them to ticket comments. - **Attachment Accessibility:** Attachments appear as links in the agent interface and notification emails. - **Attachment Properties:** Attachments are represented as JSON objects with properties such as content_type, content_url, file_name, size, etc. Given the potential sensitivity of the uploaded files (e.g., personal IDs), unauthorized access to these attachments poses a significant privacy risk. The API documentation specifies that while files are visible to any authenticated user until the upload token is consumed, once associated with a ticket, visibility is restricted. However, in this breach, the threat actor's access to the Zendesk platform could bypass these restrictions. ### Implications for Users and Organizations The breach has several profound implications: - **User Data Exposure:** Personal data, including identification documents, may have been compromised. - **Trust Erosion:** Users may lose confidence in the Internet Archive's ability to safeguard their information. - **Regulatory Scrutiny:** Potential violations of data protection regulations could lead to legal repercussions. ### Recommendations and Preventative Measures #### For Users: - **Monitor Accounts:** Keep an eye on personal accounts for any suspicious activity. - **Change Passwords:** Update passwords for accounts associated with the Internet Archive. - **Identity Protection:** Consider credit monitoring services if personal IDs were uploaded. #### For the Internet Archive and Similar Organizations: - **Rotate Credentials Regularly:** Implement policies for regular rotation of authentication tokens and API keys. - **Audit and Monitor:** Conduct frequent security audits to identify and remediate vulnerabilities. - **Implement Least Privilege Access:** Limit access permissions to only what is necessary for each role. - **Enhance Incident Response:** Develop robust incident response plans to address breaches swiftly. The Internet Archive's data breach is not just a stark reminder of the vulnerabilities that can arise from lapses in security protocols. In an era where data is a critical commodity, both organizations and users must remain super weary. Proactive security measures, timely response to threats, and user education are critical components in safeguarding against such breaches.

loading..   21-Oct-2024
loading..   6 min read