Cloud-based malware in on the rise. In this post, we’ll cover four ways you can help secure your business against cloud-based malware.
The post Cloud-based malware is on the rise. How can you secure your business? appeared first on Malwarebytes Labs.

There’s a lot of reasons to think the cloud is more secure than on-prem servers, from better data durability to more consistent patch management — but even so, there are many threats to cloud security businesses should address. Cloud-based malware is one of them.

Indeed, while cloud environments are generally more resilient to cyberthreats than on-prem infrastructure, malware delivered over the cloud increased by 68% in early 2021 — opening the door for a variety of different cyber attacks.  

But you might be asking yourself: Doesn’t my cloud provider take care of all of that cloud-based malware? Yes and no.

Your cloud provider will protect your cloud infrastructure in some areas, but under the shared responsibility model, your business is responsible for handling many security threats, incidents, responses, and more. That means, in the case of a cloud-based malware attack, you need to have a game plan ready.

In this post, we’ll cover four ways you can help secure your business against cloud-based malware.

**What ways can malware enter the cloud?**

One of the main known ways the malware can enter the cloud is through a malware injection attack. In a malware injection attack, a hacker attempts to inject malicious service, code, or even virtual machines into the cloud system.

The two most common malware injection attacks are SQL injection attacks, which target vulnerable SQL servers in the cloud infrastructure, and cross-site scripting attacks, which execute malicious scripts on victim web browsers.  Both attacks can be used to steal data or eavesdrop in the cloud.

Malware can also get into the cloud through file-upload.

Most cloud storage providers today feature file-syncing, which is when files on your local devices are automatically uploaded to the cloud as they’re modified. So, if you download a malicious file on your local device, there’s a route from there to your business’ cloud — where it can access, infect, and encrypt company data.

In fact, malware delivered through cloud storage apps such as Microsoft OneDrive, Google Drive, and Box accounted for 69% of cloud malware downloads in 2021. 

**Four best practices to prevent cloud-based malware****1\. Fix the holes in your cloud security**

As we covered in our post on cloud data breaches, there are multiple weak points that hackers use to infiltrate cloud environments — and once they find a way into your cloud, they can drop cloud-based malware such as cryptominers and ransomware.

Fixing the holes in your cloud security should be considered one of your first lines of defense against cloud-based malware. Here are three best practices:

*   **Have strong** **identity and access management (IAM)** **policies**: IAM misconfigurations cause 65% of detected cloud data breaches.

*   **Properly configure your public APIs**: Researchers have found that two-thirds of cloud data breaches were caused by misconfigured APIs.

*   **Set up your cloud storage** **correctly**: This is relevant if your cloud storage is provided as Infrastructure-as-a service (like Google Cloud Storage or Microsoft Azure Cloud Storage). By not correctly setting up your cloud storage, you risk becoming one of many companies who suffer a cloud data breach due to a misconfiguration.

**2\. Protect your endpoints to detect and remediate malware before it can enter the cloud**

Let’s say you’re the average small to mid-sized company with up to 750 total endpoints (including all company servers, employee computers, and mobile devices). Let’s also say that a good chunk of these endpoints are connected to the cloud in some way — via Microsoft OneDrive, for example.

At any time, any one of these hundreds of endpoints can become infected with malware. And if you can’t detect and remediate the malware as soon as an endpoint gets infected, there’s a chance it can sync to OneDrive — where it can infect more files.

This is why endpoint detection and response is a great “second line of defense” against cloud-based malware.

Three features of endpoint detection and response that can can help track and get rid of malware include:

*   **Suspicious activity monitoring:** EDR constantly monitors endpoints, creating a “haystack of data“ that can be analyzed to pinpoint any Indicators of Compromises (IoCs).

*   **Attack isolation**: EDR prevents lateral movement of an attack by allowing isolation of a network segment, of a single device, or of a process on the device.  

*   **Incident response**: EDR can map system changes associated with the malware, thoroughly remove the infection, and return the endpoints to a healthy state.

**3\. Use a second-opinion cloud storage scanner to detect cloud-based malware**

Even if you have fixed all the holes in your cloud security and use a top-notch EDR product, the reality is that malware can still make it through to the cloud — and that’s why regular cloud storage scanning is so important.

No matter what cloud storage service you use you likely store _a lot_ of data: a mid-sized company can easily have over 40TB of data stored in the form of millions of files. 

Needless to say, it can be difficult to monitor and control all the activity in and out of cloud storage repositories, making it easy for malware to hide in the noise as it makes its way to the cloud. That’s where cloud storage scanning comes in.

Cloud storage scanning is exactly what it sounds like: it’s a way to scan for malware in cloud storage apps like Box, Google Drive, and OneDrive. And while most cloud storage apps have malware-scanning capabilities, it’s important to have a second-opinion scanner as well.

A second-opinion cloud storage scanner is a great second line of defense for cloud storage because it’s very possible that your main scanner will fail to detect a cloud-based malware infection that your second-opinion one catches.

**4\. Have a data backup strategy in place**

The worst case scenario: You’ve properly configured your cloud, secured all your endpoints, and regularly scan your cloud storage — yet cloud-based malware still manages to slip past your defenses and encrypt all your files. 

You should have a data backup strategy in place for exactly this kind of ransomware scenario. 

When it comes to ransomware attacks in the cloud — which can cause businesses to lose critical or sensitive data — a data backup strategy is your best chance at recovering the lost files.

There are several important things to consider when implementing a data backup strategy, according to Cybersecurity and Infrastructure Security Agency (CISA) recommendations. In particular, CISA recommends using the **3-2-1 strategy.** 

The **3-2-1 strategy** means that, for every file, keep:

*   **One on a workstation**, stored locally for editing or on a local server, for ease of access.
*   **One stored on a cloud backup** solution.
*   **One stored on a long-term storage** such as a drive array, replicated offsite, or even an old school tape drive.

**Prevent cloud-based malware from getting a hold on your organization**

Cloud-based malware is one of many threats to cloud security that businesses should address, and since cloud providers operate under a shared responsibility model, you need to have a game plan ready in the case of a cloud-based malware attack. In this article, we outlined how malware can enter the cloud and four things you can do to better secure your business against it. 

Interested in reading about real-life examples of cloud-based malware? Read the case study of how a business used Malwarebytes to help eliminate cloud-based threats.

Cloud-based malware is on the rise. How can you secure your business?

A stored Cross-site Scripting (XSS) vulnerability was identified in the Data Import functionality of OpenCTI through 5.2.4. An attacker can abuse the vulnerability to upload a malicious file that will then be executed by a victim when they open the file location.

**Responsible vulnerability disclosure**

Vulnerability disclosure refers to the process of identifying, reporting and patching weaknesses of software, hardware or services that can be exploited.

Limited/Coordinated/Responsible vulnerability disclosure refers to when an identifier works with a coordinator or vendor to minimise the risk of the identified vulnerability. Once a patch has been developed, the coordinator or vendor will publish the vulnerability information alongside the remediation measures.

In the context of responsible vulnerability disclosure, ENISA coordinated together with the development team of the OpenCTI opensource project the below:

****New vulnerabilities discovered by ENISA****

**Vulnerabilities Title:** Stored XSS (CVE-2022-30289) and broken access control (CVE-2022-30290) in OpenCTI  
**Vulnerable version:** 5.2.4  
**Fixed version:** 5.3.0  
**CVE numbers:** CVE-2022-30289, CVE-2022-30290  
**Discovered:** May 2022

**Vulnerabilities Description  
**

CVE-2022-30289

A stored Cross-site Scripting (XSS) vulnerability was identified in the Data Import functionality of OpenCTI through 5.2.4. An attacker can abuse the vulnerability to upload a malicious file that will then be executed by a victim when they open the file location. 

An attacker can store malicious JavaScript by uploading a file through the Data Import functionality. This malicious JavaScript will be then executed later whenever a victim opens the file location.

CVE-2022-30290

In OpenCTI through 5.2.4, a broken access control vulnerability has been identified in the profile endpoint. An attacker can abuse the identified vulnerability in order to arbitrarily change their registered e-mail address as well as their API key, even though such action is not possible through the interface, legitimately.

An attacker can modify their e-mail address used by the system, as well as the API key, even though such action is not possible through legitimate channels. 

**Solution**

Upgrade to the latest version available: https://github.com/OpenCTI-Platform/opencti/releases

CVE-2022-30289: Vulnerability Disclosure

ASUS RT-A88U 3.0.0.4.386_45898 is vulnerable to Cross Site Scripting (XSS). The ASUS router admin panel does not sanitize the WiFI logs correctly, if an attacker was able to change the SSID of the router with a custom payload, they could achieve stored XSS on the device.

While studying for my master's degree in cyber security, I co-authored a paper regarding the rollout of IoT devices and the security considerations that businesses need to address to ensure these devices are secure. The paper underscored how a large majority of IoT devices used vulnerable components and did not follow basic secure programming principles.

As I was setting up my own new internal network in September 2021, I stumbled upon various logging functionalities within the custom deployment of DD-WRT that raised questions in my mind. DD-WRT, or in this case ASUSWRT, is a custom-developed Linux-based operating system for consumer router/modem products. Developed internally by ASUSTek, ASUSWRT builds on the standard DD-WRT distribution with a custom web interface and additional features, such as ASUSTek AiMesh networking products. The web front-end is programmed in ASP, which acts as a user interface for controlling various settings within the NVRAM of the device.

I had previously looked at router firmware but never found any vulnerabilities as such. Intrigued by the potential security-related issues that could occur if my router was hijacked, I set one of my Wi-Fi radios to a basic XSS payload to see if it had been sanitized...

“><script>alert(1)</script>

Nope, no popup...

I moved on, considering that there would be no way an XSS would be present within a software package that is so widely deployed across the world, until...

A few days later, my ISP was playing up, so I logged in to the router and navigated to the log section of the platform to see if there were any issues on my side with the router. I quickly clicked through the menus provided, one being “Wireless logs.” I suddenly had a JavaScript popup in my browser window: My original XSS had fired under the log page.

Win!

**Why Does This Matter?**

ASUS routers have a functionality named **Remote Management** that allows for users to connect back to their home routers over HTTP, over port 8443. This also allows users to attach devices, such as USB pen drives, to their router to effectively turn it into a router/network attached storage combo unit.

An attacker with pre-existing access to a router could use this vulnerability to maintain persistence to the router, even after a password reset/IP address change. An attacker could additionally leverage this exploit to change any setting on the router, including Wi-Fi passwords and DNS servers, and enabling telnet/SSH. **Ultimately, this exploit allows for complete takeover of a compromised router when chained with basic Unix knowledge**.

It would be trivial to create a Shodan search query to pull in all ASUS router products accessible from the internet (Figure 1) (Table 1). Although the user must set their own password from the default one provided by the manufacturer to first access the web admin interface, cybercriminals know all too well that users commonly reuse passwords.

Figure 1 – Exposed ASUS Routers Globally

Vulnerable Firmware/Device – 3.0.0.4.386.46061

All Zen WiFi lineup

RT-AC66U B1 

All 802.11axl lineup

RT-AC66U+

All ROG Rapture lineup

RT-AC1300UHP/ G+

All TUF Gaming lineup

RT-AC1200

RT-AC5300

RT-AC1200G/HP/G+/ E/ GU

RT-AC3100

RT-AC58U

RT-AC88U

RT-AC56U/R/S

RT-AC3200

RT-AC55U

RT-AC2900

RT-AC55UHP

RT-AC2600

RT-AC53

RT-AC2400

RT-AC52U B1

RT-AC2200

RT-AC51U/ U+

RT-AC87U/R

RT-ACRH17

RT-AC86U

RT-ACRH13

RT-AC85U

RT-N66U/R/W/C1

RT-AC85P

RT-N18U

RT-AC65P

RT-N19

RT-AC57U

RT-N14UHP

RT-AC68U/R/P/W/UF

RT-N12E B1/C1

RT-AC65U

RT-N12HP B1

RT-AC1900

RT-N12VP B1

RT-AC1900P/U

RT-N12+ B1

RT-AC1750

RT-N12D1

RT-AC1750 B1 

4G-AC53U

RT-AC66U/R/W

4G-AC68U

Table 1 – Vulnerable Firmware to Devices

**Code Analysis**

I subsequently dumped the firmware from a vulnerable version, accessed via the ASUSTek update page.

Upon downloading the file, you will be presented with a **.trx** file, which is effectively a zip containing the mount points for the operating system. The web front-end is stored within the **/www** folder, and in this case, the vulnerable code is located within the **Main\_WStatus\_Content.asp** file.

This file preforms a GET request to **/wl\_log.asp** upon accessing the page. Within this request, the SSID of the router will also be returned, among data such as MAC addresses, access time for clients, and some other general debug information. The page then uses the following code to convert elements within the log, back to readable format, HTML encoding them in the process:

Function(resp){  
Content = htmlEnDeCode.htmlEncode(resp);  
Content = classObj.UnHexCode(content);  
\--- Snip ---

While this page attempts to decode the information provided by the GET request, in doing so, there is no filtering for malicious content, such as HTML tags. The script then continues and places the data within a <textarea> HTML element; in this case, the XSS payload is processed by the browser and the vulnerability has been exploited. The user’s browser will execute the payload and the attacker has control over the device.

**Vulnerability Submission and Patch Released**

I subsequently contacted ASUSTek on October 28, 2021, at 3:40 p.m. (UTC). The ASUS Security department (“ASUS security”) first requested that I update my firmware version to 386\_45898 to verify that the vulnerability existed on the latest release of the firmware. After updating the software, I confirmed that the firmware was still vulnerable to the exploit.

ASUS security then requested a proof-of-concept script/video of the attack for their internal reference. After I provided a short 20-second clip of the vulnerability in action, ASUS security immediately accepted the submission.

Shortly after sending the proof-of-concept video, I received an email from ASUS security requesting that I install a new beta patch for the router product. After I personally confirmed that ASUS had patched the vulnerability in the beta branch of the firmware, ASUS requested my information so I could be acknowledged in the patch notes of the firmware (Figure 1). The beta firmware was subsequently published as the latest firmware update for the affected products.

Figure 2 – Firmware Patch Notes Acknowledgement

**CVE Assignment**

A CVE was requested for this issue on November 11, 2021, which MITRE subsequently issued on March 28, 2022, as CVE-2021-43702. As of this writing, MITRE has not published further details, but I’ll update this article when more information becomes available.

CVE-2021-43702: CVE-2021-43702 from Discovery to Patch | Kroll

Cross-site Scripting (XSS) - Stored in GitHub repository microweber/microweber prior to 1.2.19.

**Cross-site Scripting in microweber**

Moderate severity GitHub Reviewed Published Jul 5, 2022 • Updated Jul 6, 2022

GHSA-q6mp-562x-ggvv: Cross-site Scripting in microweber

Education institution will pay up to $2,500 for valid vulnerabilities

James Walker 04 July 2022 at 14:28 UTC

Education institution will pay up to $2,500 for valid vulnerabilities

Monash University in Melbourne, Australia, has launched a public bug bounty program to help maintain the security of its digital platforms.

The new program, which is being hosted on the Bugcrowd platform, will reward security researchers up to $2,500 for valid vulnerabilities.

In-scope targets include the main Monash University web domain and mobile apps, along with various technologies that are used by the institution, including its VPN and FileShare instances.

Cross-site scripting (XSS), DNS configuration issues, and low-impact cross-site request forgery (CSRF) issues are all out of scope.

**‘Final maturity step’**

Established in 1958, Monash is home to several major research facilities and is consistently ranked in the world’s top 100 universities.

According to Dan Maslin, Monash University’s CISO, the move marks the “final maturity step” in the university’s multi-year journey.

Read more bug bounty news

“The program reflects Monash University’s commitment to protecting the confidentiality, integrity, and availability of its information and digital platforms,” Maslin said.

“We value and support the work undertaken by the cybersecurity research community and appreciate it when researchers take the time to report potential security vulnerabilities to us – we welcome submissions from cybersecurity researchers globally.”

**Education threat**

Universities and other education establishments around the world have witnessed dozens of cyber-attacks over recent months, with ransomware being a particular cause for concern.

In May, the Chicago Public School system warned parents that the personal records of more than 495,000 children may have been exposed as the result of a ransomware attack on a third-party supplier.

In eastern Europe, at least 30 Ukrainian university websites were hacked in a targeted attack thought to have been in support of Russia’s ongoing invasion of the country.

And in 2020, Melbourne Polytechnic in Australia announced that a data breach had impacted the personal data of around 90,000 staff, students, and suppliers.

**YOU MIGHT ALSO LIKE** Bug Bounty Radar // The latest bug bounty programs for July 2022

Australia’s Monash University launches public bug bounty program

Paymoney version 3.3 suffers from a cross site scripting vulnerability.

    ## Title: paymoney-3.3 XSS-Reflected## Author: nu11secur1ty## Date: 07.02.2022## Vendor: https://paymoney.techvill.org/## Software: paymoney-3.3## Reference: https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/paymoney/2022/paymoney-3.3Description:The parameters first_name and last_name in Users are vulnerable fromXSS-Reflected on Paymoney-3.3. The already authenticated users can behijacking the XSRF-Token and they can use it for malicious purposes oninternal and external domains.STATUS: Medium## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/paymoney/2022/paymoney-3.3)## Proof and Exploit:[href](https://streamable.com/fhzvyr)

Paymoney 3.3 Cross Site Scripting

The Gallery WordPress plugin before 2.0.0 does not sanitise and escape a parameter before outputting it back in the response of an AJAX action (available to both unauthenticated and authenticated users), leading to a Reflected Cross-Site Scripting issue

CVE-2022-1946

The WP Contact Slider WordPress plugin before 2.4.7 does not sanitize and escape the Text to Display settings of sliders, which could allow high privileged users such as editor and above to perform Cross-Site Scripting attacks even when the unfiltered_html is disallowed

CVE-2022-1301

The Redirection for Contact Form 7 WordPress plugin before 2.5.0 does not escape a link generated before outputting it in an attribute, leading to a Reflected Cross-Site Scripting

CVE-2022-0250

The Ninja Forms Contact Form WordPress plugin before 3.6.10 does not sanitize and escape some imported data, allowing high privilege users to perform Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed.

Tag

#xss