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...

QNAP

Zero Day

loading..
loading..
loading..

QNAP Patched a Major Zero-Day Vulnerability on NAS Devices After Pwn2Own 2024

QNAP patches a critical zero-day vulnerability in NAS devices post-Pwn2Own 2024 hack, boosting NAS security with updates for HBS 3 Backup Sync

30-Oct-2024
4 min read

Related Articles

loading..

WarmCookie

New 'WarmCookie' malware spreads in France through fake browser updates, posing ...

A new wave of cyber espionage, meticulously crafted through a strategy known as "FakeUpdate," has been targeting users in France, leveraging compromised websites to push fake update notifications for popular applications. At the heart of this operation is the sophisticated _"WarmCookie"_ backdoor, deployed by the elusive threat group, [SocGolish](https://www.secureblink.com/cyber-security-news/fake-microsoft-teams-infects-networks-of-various-companies-using-cobalt-strike). By disguising itself as legitimate software updates, WarmCookie has gained an unprecedented reach, with the latest enhancements adding layers of complexity and danger to this backdoor. ### WarmCookie's Evolution and Deployment First identified by cybersecurity firm [eSentire](https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-resident-campaign) in mid-2023, WarmCookie quickly distinguished itself with broad, multi-functional capabilities tailored to Windows systems. Traditionally, it has spread through phishing emails, often masquerading as job offers. In the current campaign, however, WarmCookie is distributed via FakeUpdate attacks, where fake updates mimic widely trusted applications such as [Google Chrome](https://www.secureblink.com/cyber-security-news/google-chrome-patches-tenth-zero-day-of-2024-exploited-in-the-wild), [Mozilla Firefox](https://www.secureblink.com/cyber-security-news/firefox-hacked-update-now-to-patch-actively-exploited-zero-day), Microsoft Edge, and Java. The attackers behind WarmCookie are deploying this malware using highly convincing fake update prompts displayed on compromised websites. Once users click the prompts, WarmCookie is silently installed on their systems, enabling the threat actors to take control and harvest valuable data. ### WarmCookie’s Core Capabilities The technical intricacies of WarmCookie illustrate a calculated approach to data theft and remote control. Its capabilities include: WarmCookie efficiently locates and exfiltrates files, focusing on sensitive data that can be monetized or weaponized for further attacks. The malware gathers detailed information about the infected device’s configuration, including hardware, software, and network characteristics, essential for tailoring subsequent attack strategies. By scanning the Windows Registry, WarmCookie identifies installed applications and system configurations, optimizing its actions based on the system environment. WarmCookie can execute arbitrary commands, allowing the attackers to alter system files, modify permissions, or introduce additional malware. The malware has built-in screenshot-capturing abilities, which are instrumental for gathering visual context on the target's activity. Additional Payload Introduction: Beyond its core functions, WarmCookie serves as a delivery mechanism for secondary payloads, intensifying its impact on compromised systems. These features not only reinforce WarmCookie’s versatility but also highlight the attackers' ability to adapt to various operational environments. ### Enhancements in the Latest Campaign The current campaign, monitored by [Gen Threat Labs](https://x.com/GenThreatLabs/status/1840762181668741130), reveals that WarmCookie has been updated with new functionalities that expand its threat scope: WarmCookie now stores and executes dynamic link libraries (DLLs) from temporary directories, complicating detection by traditional endpoint security solutions. The backdoor can transfer and run EXE and PowerShell files on infected devices, an enhancement that gives the attackers direct, remote control over system processes. The malware conducts anti-VM (virtual machine) checks to evade detection by analysts running virtualized environments, ensuring WarmCookie operates only in genuine user environments. This set of advancements marks a significant evolution in WarmCookie’s architecture, enhancing its ability to persist on targeted systems and effectively resist forensic analysis. ### Infection Chain: Exploiting the FakeUpdate Mechanism The infection process is both seamless and deceptive. It starts with a fake update notification on a compromised or maliciously designed website. Once a user clicks the prompt, JavaScript initiates the download of WarmCookie, disguised as a legitimate installer. This fake installer, once executed, installs WarmCookie on the system, often without visible alerts to the user. ![infection-chain.jpeg](https://sb-cms.s3.ap-south-1.amazonaws.com/infection_chain_d9550a894c.jpeg) ***New WarmCookie Infection Chain (source: Gen Threat Labs)*** During installation, WarmCookie performs anti-VM checks to verify that it is running on a real machine rather than in a sandboxed or virtual environment. Once confirmed, it transmits a detailed fingerprint of the system to the command-and-control (C2) server, awaiting further commands. The process is seamless, and victims are typically unaware of the compromise. ### Strategic Use of FakeUpdate Campaigns in France This particular campaign by SocGolish primarily targets French users, exploiting trust in familiar brands like Chrome and Java. Domains such as _"edgeupdate[.]com"_ and _"mozilaupgrade[.]com"_ have been utilized to replicate the visual elements of genuine updates, adding credibility to the prompts and making detection challenging for everyday users. ### Defensive Measures and Best Practices Given the sophistication of WarmCookie and the deceptive nature of FakeUpdate campaigns, vigilance is essential. Users should be reminded that: Modern browsers update in the background, requiring only a restart in most cases. Manual updates should be verified directly through the official website of each software provider. Fake update prompts can appear on seemingly trustworthy websites due to compromised content, so skepticism is warranted, even on familiar sites. In this campaign, SocGolish’s calculated methods—targeting unsuspecting users with legitimate-seeming prompts and leveraging WarmCookie’s capabilities—reveal an elevated level of technical and psychological strategy. Staying updated on the latest developments in malware campaigns like FakeUpdate is crucial for users and organizations alike, as WarmCookie’s expanding abilities demonstrate a clear trajectory toward even more targeted and persistent attacks in the future.

loading..   25-Oct-2024
loading..   5 min read
loading..

CDK

AWS

S3

Discover how missing S3 buckets in AWS CDK can lead to account takeover. Learn h...

A security vulnerability was discovered in the [AWS](https://www.secureblink.com/cyber-security-news/15-000-aws-load-balancers-at-risk-secure-your-apps-from-al-beast-vulnerability-now) Cloud Development Kit (CDK), an open-source framework that allows developers to define cloud infrastructure using familiar programming languages. This vulnerability could, under specific circumstances, enable an attacker to gain administrative access to a target AWS account, leading to a full account takeover. This [Threatfeed](https://www.secureblink.com/cyber-security-news) delves into the nature of the vulnerability, the conditions under which it can be exploited, and the steps taken to mitigate the risk. ### AWS CDK and Infrastructure as Code Infrastructure as Code (IaC) revolutionizes the way computing infrastructure is managed and provisioned by utilizing code instead of manual configurations. It allows developers to define essential infrastructure components—such as servers, databases, and networks—through machine-readable files. The AWS Cloud Development Kit (CDK) is a framework that enables developers to define cloud infrastructure using familiar programming languages like [Python](https://www.secureblink.com/cyber-security-news/python-repo-hit-by-phony-dmca-takedown-restored-by-git-hub), TypeScript, or [JavaScript](https://www.secureblink.com/cyber-security-news/50-k-users-from-40-banks-globally-targeted-by-new-java-script-malware). CDK translates this code into AWS CloudFormation templates, which AWS can interpret and deploy efficiently. This approach streamlines the process of building and managing cloud infrastructure, allowing developers to write, customize, and deploy cloud resources directly from their codebase. --- ### Understanding the CDK Bootstrap Process Before deploying applications using AWS CDK, users must bootstrap their environment using the cdk bootstrap command. This process deploys a CloudFormation template that automatically creates essential infrastructure components, including: [IAM Roles](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-env.html#bootstrapping-env-default) and Policies: Roles like FilePublishingRole and CloudFormationExecutionRole are created. The FilePublishingRole allows CDK to interact with the bootstrapped S3 bucket for uploading and deleting assets. The CloudFormationExecutionRole grants CloudFormation permission to perform stack deployments on the user's behalf, typically with administrative privileges by default. A staging S3 bucket is created to store deployment assets, such as CloudFormation templates and other resources. These assets are first generated and saved locally in the cdk.out directory before being uploaded to the S3 staging bucket for use during the deployment process. ### Naming Conventions The resources created during the bootstrap process follow a predictable naming pattern: `cdk-{Qualifier}-{Description}-{Account-ID}-{Region}` A unique, nine-character string value. By default, this is hnb659fds, but users can customize it. A short descriptor of the resource (e.g., cfn-exec-role for CloudFormationExecutionRole). Account-ID: The AWS account ID. Region: The AWS Region where the CDK is deployed. For example, the CloudFormationExecutionRole might be named: `cdk-hnb659fds-cfn-exec-role-123456789012-us-east-1` --- ### Exploiting Missing S3 Buckets #### Predictable Bucket Names and Shadow Resources The staging S3 bucket's name is predictable, especially when users use the default qualifier. It follows the pattern: `cdk-{Qualifier}-assets-{Account-ID}-{Region}` Given that many users do not [customize the qualifier](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping-troubleshoot.html), using the default hnb659fds, attackers can predict the bucket name if they know the AWS Account ID and the Region. #### S3 Bucket Namesquatting Since S3 bucket names are globally unique, an attacker can perform _"S3 Bucket Namesquatting"_ or _"Bucket Sniping"_ by creating a bucket with the predicted name if it doesn't already exist. This situation can occur in two scenarios: 1. **New CDK Users:** If a user has not yet bootstrapped their CDK environment, an attacker can preemptively create the staging bucket. When the user attempts to bootstrap, the process fails due to the bucket's existence, causing a partial denial-of-service (DoS). The user can resolve this by using a custom qualifier. 2. **Deleted Staging Buckets:** If a user previously bootstrapped CDK but later manually deleted the staging S3 bucket—perhaps to free up resources—the bucket name becomes available. An attacker can then claim this bucket. ### Implications of the Attack When the user performs a cdk deploy, the CDK uses existing roles and resources, including the CloudFormationExecutionRole with administrative privileges. If the staging bucket is under the attacker's control: The CDK uploads deployment assets, including CloudFormation templates, to the attacker's bucket. The attacker can intercept and modify the templates, injecting malicious code or resources. CloudFormation, using its administrative role, deploys these tampered templates in the victim's account. The attacker can create an admin role within the victim's account, which they can assume to gain full administrative access. --- ### Attack Workflow and Potential Impact #### Pre-Attack Setup by the Attacker 1.The attacker creates the staging S3 bucket with the predictable name corresponding to the victim's account and region. 2.The attacker sets permissive policies on the bucket to allow public access and interaction. 3.A Lambda function is configured to trigger on PutObject events, designed to inject malicious resources into any uploaded CloudFormation template. ### Attack Execution Steps 1. User Deploys CDK Application: The victim runs cdk deploy, unaware that the staging bucket is controlled by the attacker. 2. Asset Upload: The CDK uploads the CloudFormation template to the attacker's bucket. 3. Template Tampering: The attacker's Lambda function modifies the template, injecting a new admin role or other malicious resources. 4. Deployment of Malicious Template: CloudFormation in the victim's account retrieves and deploys the tampered template, using the CloudFormationExecutionRole with administrative privileges. 5. Attacker Gains Access: The newly created admin role allows the attacker to assume administrative access to the victim's [AWS](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) account. ### Severity of the Impact This vulnerability enables a complete compromise of the victim's AWS account, granting the attacker the ability to: - Access and manipulate resources. - Exfiltrate sensitive data. - Launch further attacks or exploitations. --- ### Statistical Analysis of Affected Users To assess the prevalence of this vulnerability, a study was conducted: Dataset: A list of 38,560 well-known AWS Account IDs. Regions Scanned: us-east-1, us-west-2, and eu-west-1. #### Methodology: Checked for the existence of the CloudFormationExecutionRole to confirm CDK usage. Verified whether the corresponding staging S3 bucket existed. #### Findings: CDK Usage: 782 accounts (2%) had CDK roles, indicating CDK usage. Vulnerable Accounts: 81 accounts (10% of CDK users) lacked the staging S3 bucket, making them susceptible to the attack. AWS Confirmation: AWS corroborated that approximately 1% of [CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html) users were impacted. --- ### Mitigation Strategies #### AWS's Response Following the disclosure, AWS implemented several fixes: In CDK version [v2.149.0](https://github.com/aws/aws-cdk/releases/tag/v2.149.0), a condition was added to the FilePublishingRole to ensure it only trusts S3 buckets within the user's account. AWS [emphasized](https://github.com/search?q=/cdk-hnb659fds-(.+-)%257B1,5%257D%255Cd/&type=code) the importance of customizing bootstrapping resources and using a custom qualifier. Direct communication with potentially affected customers. CLI terminal messages prompting users to upgrade bootstrap resources. ### Required User Actions Despite AWS's fixes, user intervention is necessary: Upgrade CDK: Update to CDK version v2.149.0 or later. Re-run the cdk bootstrap command to apply the new configurations. #### Manual Role Adjustment: If upgrading is not immediate, modify the FilePublishingRole IAM policy. Add a condition to restrict the role to trust only [S3 buckets](https://onecloudplease.com/blog/s3-bucket-namesquatting) within the user's account. --- ### Recommendations and Best Practices To safeguard against similar vulnerabilities, users should adopt the following practices: 1. Treat AWS Account IDs as Sensitive: Avoid sharing AWS Account IDs publicly. Recognize that knowledge of an account ID can facilitate targeted attacks. 2. Customize Bootstrapping Qualifier: Always specify a custom --qualifier when running cdk bootstrap. This reduces the predictability of resource names. 3. Implement IAM Policy Conditions: Use conditions like aws:ResourceAccount in IAM policies to restrict access based on the bucket owner's AWS account ID. Ensure that roles and policies are scoped appropriately to prevent unauthorized access. 4. Avoid Predictable Resource Names: Incorporate unique identifiers or hashes into resource names, especially for globally unique services like S3. This prevents attackers from predicting and preemptively claiming resource names. 5. Regularly Audit and Monitor Resources: Periodically check for missing or inadvertently deleted resources critical for deployment processes. Monitor logs and alerts for unusual activities during deployment. --- Disclosure Timeline 27 June 2024: Security issue reported to the AWS security team. 27 June 2024: AWS acknowledged the report and initiated investigation. 11 July 2024: Pull request opened to fix the issue by adding a condition to the bootstrap FilePublishingRole. 12 July 2024: Pull request merged; fix available in CDK version v2.149.0. 09 August 2024: AWS confirmed completion of remediation efforts and updated documentation. 15 October 2024: AWS notified impacted customers. 16 October 2024: AWS added CLI terminal messages alerting users to upgrade bootstrap resources.

loading..   24-Oct-2024
loading..   8 min read
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