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

cyberthreat

hacking

loading..
loading..
loading..

Middle East Cyberthreat

Chafer APT Hits Middle East Governments With Cyber-Espionage Attacks, and suspected to have more links

01-Jun-2020
2 min read

Related Articles

loading..

Zero Day

QNAP

QNAP patches a critical zero-day vulnerability in NAS devices post-Pwn2Own 2024 ...

QNAP has addressed a critical zero-day vulnerability exploited by security researchers to hack a TS-464 NAS device during the Pwn2Own Ireland 2024 competition. This vulnerability, designated **CVE-2024-50388**, is rooted in an OS command injection weakness in the HBS 3 Hybrid Backup Sync software, which serves as QNAP's solution for disaster recovery and data backup. --- #### Overview of the Vulnerability The flaw in question, CVE-2024-50388, was identified in [HBS 3 Hybrid Backup Sync](https://www.qnap.com/en/software/hybrid-backup-sync) version 25.1.x. The vulnerability poses a significant risk, as it could enable remote attackers to execute arbitrary commands on affected devices, potentially gaining unauthorized access. > **QNAP Security Advisory:** > "An OS command injection vulnerability has been reported to affect HBS 3 Hybrid Backup Sync. If exploited, the vulnerability could allow remote attackers to execute arbitrary commands," QNAP [said](https://www.qnap.com/en/security-advisory/qsa-24-41) in a Tuesday security advisory. --- #### Update and Patch Information QNAP has issued a patch in **HBS 3 Hybrid Backup Sync version 25.1.1.673** and later to address this critical vulnerability. To protect your NAS device from potential exploits, it is essential to ensure your HBS 3 installation is up-to-date. ##### How to Update HBS 3: 1. **Log in to QTS or QuTS Hero** as an administrator. 2. **Open the App Center** and search for "HBS 3 Hybrid Backup Sync." 3. If an update is available, click on **Update**. Note: If the “Update” button is missing, your HBS 3 is already current. --- #### Exploit Demonstration at Pwn2Own The vulnerability came to light during the **Pwn2Own Ireland 2024** competition, where security researchers Ha The Long and Ha Anh Hoang from Viettel Cyber Security successfully leveraged it to gain [administrative privileges](https://x.com/thezdi/status/1849372314212749751) on QNAP’s TS-464 NAS device. Notably, **Team Viettel** secured victory in the Pwn2Own competition, held over four days and concluded on October 25, 2024. The team won substantial prizes, contributing to a total pool exceeding $1 million, by disclosing over 70 [zero-day vulnerabilities](https://www.secureblink.com/cyber-security-news/80-000-devices-vulnerable-to-qnap-zero-day-vulnerability) across various devices and applications. --- #### Patch Timing and Industry Standard Response QNAP’s response to this zero-day vulnerability is considered swift, with the patch released five days after the exploit was demonstrated. Typically, vendors participating in Pwn2Own are granted a 90-day window to address reported vulnerabilities before the **Zero Day Initiative (ZDI)**, run by Trend Micro, publishes detailed information on the vulnerabilities disclosed during the contest. --- ### Historical Context: QNAP's Vulnerability Challenges QNAP devices have been a frequent target for cyber threats over the years, particularly by ransomware gangs due to the sensitive personal and organizational data they store. Below are some notable historical vulnerabilities and attacks against QNAP devices: 1. **Backdoor Account Removal ([CVE-2021-28799}(https://www.qnap.com/en/security-advisory/QSA-21-13)):** In 2021, QNAP removed a backdoor account in the HBS 3 Hybrid Backup Sync. This vulnerability was exploited in conjunction with an **[SQL injection vulnerability](https://www.qnap.com/de-de/security-advisory/qsa-21-11) ([CVE-2020-36195](https://nvd.nist.gov/vuln/detail/CVE-2020-36195))** in QNAP’s Multimedia Console and Media Streaming Add-On. Attackers used these flaws to deploy **[Qlocker ransomware](https://www.secureblink.com/cyber-security-news/qlocker-resurrected-with-a-new-campaign-in-targeting-qnap-nas-devices-once-again)**, encrypting files on Internet-exposed NAS devices. 2. **eCh0raix Ransomware Attacks (2020-2021):** QNAP NAS devices faced extensive ransomware attacks leveraging known security flaws. In June 2020, QNAP warned users of **[eCh0raix](https://www.secureblink.com/cyber-security-news/qnap-nas-devices-yet-again-victimized-due-to-rise-of-ech0raix) (QNAPCrypt) ransomware**, which exploited vulnerabilities in the Photo Station app. By mid-2021, attackers using eCh0raix reemerged, taking advantage of weak user passwords and unresolved vulnerabilities. 3. **AgeLocker Ransomware Attacks (September 2020):** AgeLocker ransomware targeted NAS devices running outdated Photo Station software versions. This attack highlighted the risks associated with publicly exposed NAS devices that lack regular updates or security patches. QNAP NAS devices continue to be attractive to ransomware groups due to the personal and sensitive nature of the data stored on these systems. Cybercriminals often leverage this data to demand ransoms, knowing that victims may pay to regain access to their critical files. QNAP’s quick response in patching the HBS 3 zero-day vulnerability shows a proactive approach to securing their systems against emerging threats. As NAS devices remain a popular yet viable target for threat actors, keeping such devices updated with the latest security patches often remains non-negotiable for preventing exploitation and minimizing data loss.

loading..   30-Oct-2024
loading..   4 min read
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